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: 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 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
> > ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
> > ACPI: MADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100
> > ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
> > ACPI: PM-Timer IO Port: 0x1008
> > ACPI: Local APIC address 0xfee0
> > 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[0xfec0] gsi_base[0])
> > IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
> > Using ACPI (MADT) for SMP configuration information
> >
>
> ACPI: acpi_table_parse(17, ) 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
Jiri Slaby wrote: >> On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote: >>> What do you see if on failure you also print out the params, like below? [...] > ACPI: acpi_table_parse(17, ) HPET NULL handler! After re-enabling HPET, it disappeared. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
> ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
> ACPI: MADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100
> ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
> ACPI: PM-Timer IO Port: 0x1008
> ACPI: Local APIC address 0xfee0
> 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[0xfec0] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
> Using ACPI (MADT) for SMP configuration information
>
ACPI: RSDP (v000 ACPIAM) @ 0x000f9e30
ACPI: RSDT (v001 A M I OEMRSDT 0x1414 MSFT 0x0097) @ 0x7ff3
ACPI: FADT (v002 A M I OEMFACP 0x1414 MSFT 0x0097) @ 0x7ff30200
ACPI: MADT (v001 A M I OEMAPIC 0x1414 MSFT 0x0097) @ 0x7ff30390
ACPI: OEMB (v001 A M I OEMBIOS 0x1414 MSFT 0x0097) @ 0x7ff40040
ACPI: DSDT (v001 P4P81 P4P81104 0x0104 INTL 0x02002026) @ 0x
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
Using ACPI (MADT) for SMP configuration information
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
ACPI: MADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100
ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
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[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
Using ACPI (MADT) for SMP configuration information
reagrds,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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'm sorry, I might not be able to try it until monday. Michal reported
a similar problem though, adding him to CC list.
Regards,
Frederik
> thanks,
> -Len
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 3fce3db..e2d08a5 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -415,7 +415,12 @@ int __init acpi_table_parse(enum acpi_table_id id,
> acpi_table_handler handler)
> unsigned int index = 0;
> unsigned int count = 0;
>
> - BUG_ON(!handler);
> + if (!handler) {
> + printk(KERN_WARNING PREFIX
> + "acpi_table_parse(%d, %p) %s NULL handler!\n",
> + id, handler, acpi_table_signatures[id]);
> + return -EINVAL;
> + }
>
> for (i = 0; i < sdt_count; i++) {
> if (sdt_entry[i].id != id)
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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?
thanks,
-Len
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 3fce3db..e2d08a5 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -415,7 +415,12 @@ int __init acpi_table_parse(enum acpi_table_id id,
acpi_table_handler handler)
unsigned int index = 0;
unsigned int count = 0;
- BUG_ON(!handler);
+ if (!handler) {
+ printk(KERN_WARNING PREFIX
+ "acpi_table_parse(%d, %p) %s NULL handler!\n",
+ id, handler, acpi_table_signatures[id]);
+ return -EINVAL;
+ }
for (i = 0; i < sdt_count; i++) {
if (sdt_entry[i].id != id)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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?
Regards,
Frederik
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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?
Regards,
Frederik
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)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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?
thanks,
-Len
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 3fce3db..e2d08a5 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -415,7 +415,12 @@ int __init acpi_table_parse(enum acpi_table_id id,
acpi_table_handler handler)
unsigned int index = 0;
unsigned int count = 0;
- BUG_ON(!handler);
+ if (!handler) {
+ printk(KERN_WARNING PREFIX
+ acpi_table_parse(%d, %p) %s NULL handler!\n,
+ id, handler, acpi_table_signatures[id]);
+ return -EINVAL;
+ }
for (i = 0; i sdt_count; i++) {
if (sdt_entry[i].id != id)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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'm sorry, I might not be able to try it until monday. Michal reported
a similar problem though, adding him to CC list.
Regards,
Frederik
thanks,
-Len
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 3fce3db..e2d08a5 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -415,7 +415,12 @@ int __init acpi_table_parse(enum acpi_table_id id,
acpi_table_handler handler)
unsigned int index = 0;
unsigned int count = 0;
- BUG_ON(!handler);
+ if (!handler) {
+ printk(KERN_WARNING PREFIX
+ acpi_table_parse(%d, %p) %s NULL handler!\n,
+ id, handler, acpi_table_signatures[id]);
+ return -EINVAL;
+ }
for (i = 0; i sdt_count; i++) {
if (sdt_entry[i].id != id)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
ACPI: MADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100
ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
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[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
Using ACPI (MADT) for SMP configuration information
reagrds,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
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: 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 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
ACPI: MADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100
ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
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[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
Using ACPI (MADT) for SMP configuration information
ACPI: RSDP (v000 ACPIAM) @ 0x000f9e30
ACPI: RSDT (v001 A M I OEMRSDT 0x1414 MSFT 0x0097) @ 0x7ff3
ACPI: FADT (v002 A M I OEMFACP 0x1414 MSFT 0x0097) @ 0x7ff30200
ACPI: MADT (v001 A M I OEMAPIC 0x1414 MSFT 0x0097) @ 0x7ff30390
ACPI: OEMB (v001 A M I OEMBIOS 0x1414 MSFT 0x0097) @ 0x7ff40040
ACPI: DSDT (v001 P4P81 P4P81104 0x0104 INTL 0x02002026) @ 0x
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
Using ACPI (MADT) for SMP configuration information
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1)
Jiri Slaby wrote: On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote: What do you see if on failure you also print out the params, like below? [...] ACPI: acpi_table_parse(17, ) HPET NULL handler! After re-enabling HPET, it disappeared. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 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 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000
ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040
ACPI: MADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100
ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
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[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, 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, ) HPET NULL handler!
Using ACPI (MADT) for SMP configuration information
ACPI: acpi_table_parse(17, ) 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
