[lkml]   [2004]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ACPI] Re: hangs on boot with ACPI
    Pontus Fuchs wrote:
    > On Thu, 2004-08-19 at 08:49, Len Brown wrote:
    >>On Tue, 2004-08-17 at 04:55, Pontus Fuchs wrote:
    >>>After upgrading to from plain my machine does not
    >>>boot anymore. The last message i see is:
    >>>ACPI: Processor [CPU0] (supports C1,C2,C3, 8 throttling states)
    >>>In plain the next messages would be:
    >>>ACPI: Thermal Zone [THRM] (52 C)
    >>>Console: switching to colour frame buffer device 175x65
    >>>Linux agpgart interface v0.100 (c) Dave Jones
    >>>agpgart: Detected SiS 648 chipset
    >>>Booting with acpi=off works fine. I have also tried pci=routeirq but
    >>>does not make any difference.
    >>>The machine is an Asus L5c laptop.
    >>Please try booting with "pci=routeirq"
    >>If that doesn't work, please take stock and apply the latest
    >>patch here:
    >>and give it a go.
    >>This will bring your kernel up to the same ACPI patch that is in the -mm
    >>tree, but without all the other stuff in the mm tree.
    >>If it fails, then ACPI broke. If it works, then something in -mm broke
    > Hi,
    > I found this another Asus laptop with intel chipset which also has
    > problems with the latest ACPI code, and I tried the same trick on my
    > machine, and now the machine boots again!
    > I have no clue what I'm actually doing so please don't consider the
    > patch a fix for the problem, but rather a way do show how to make the
    > symptom go away.
    > --- quirks.c.bak 2004-08-19 13:25:23.000000000 +0200
    > +++ quirks.c 2004-08-19 13:25:47.000000000 +0200
    > @@ -756,11 +756,13 @@
    > */
    > static void __init quirk_sis_96x_smbus(struct pci_dev *dev)
    > {
    > +/*
    > u8 val = 0;
    > printk(KERN_INFO "Enabling SiS 96x SMBus.\n");
    > pci_read_config_byte(dev, 0x77, &val);
    > pci_write_config_byte(dev, 0x77, val & ~0x10);
    > pci_read_config_byte(dev, 0x77, &val);
    > +*/
    > }

    Well the problem is not really in the ACPI code, but rather in the PCI
    code that tries to inconditionnaly enable SMBus and thus PCI devices
    without _also_ honoring the firmware configured IO port regions for the
    devices it just enabled. Thus, when ACPI use the DTST to also map the
    same IO ports regions that obviously assume the default firmware value,
    ACPI fails.

    Current victimcs are :
    - Asus L3C, L5C users,
    - Probably any user of pci quirk.c code that enables the SMbus...

    On the L3C at least, the code to enable the SMBus works perfectly, the
    firmware configured value for the IO region is coherent with what the
    DTST contains but the PCI code change PCI configuration space default
    value and thus breaks ACPI...

    / ` Eric Valette
    /-- __ o _. 6 rue Paul Le Flem
    (___, / (_(_(__ 35740 Pace

    Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.024 / U:1.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site