Bug 10749

Created attachment 16201 [details]
.config

Hi, Riccardo
    It seems that it is a regression. Will you please try to use git-bisect to identify which commit brings the regression?
    Will you please attach the output of acpidump?
    Thanks.

Hello,
unfortunately until friday I don't have access to my PC. On saturday I'll try to bisect the kernel and I'll post acpidump output.
Sorry

git bisect says that:

4764b68405ac918e9ac9939b1a2d1469102e5af7 is first bad commit
commit 4764b68405ac918e9ac9939b1a2d1469102e5af7
Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date:   Sat Apr 26 17:36:43 2008 +0200

    sis5513: fail early for unsupported chipsets

    * Factor out chipset family detection from init_chipset_sis5513()
      to sis_find_family().

    * Use sis_find_family() in sis5513_init_one() to fail early if the
      chipset is unsupported.

    * Keep a local copy sis5513_chipset in sis5513_init_one()
      and set .udma_mask according to chipset family.

    * Remove no longer need ->ultra_mask setting from init_hwif_sis5513().

    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Bart, can you look at this 2.6.26-rc regression?

I already did, see:

http://lkml.org/lkml/2008/5/25/149

ACPI errors in the dmesg seem to confirm that this is not an sis5513 problem,

I'm reverting it back to ACPI for now.

There are a lot of ACPI error messages in the dmesg of 
>r (psparse-0537): Method parse/execution failed [\ISMI] (Node f7c18630), 
AE_NO_MEMORY
>ACPI Error (psparse-0537): Method parse/execution failed 
>[\_SB_.PCI0.PX40.MIDI._STA] (Node f7c1ef68), AE_NO_MEMORY
>ACPI Error (exregion-0164): Could not map memory at F7C218943FFFFF00, size 200 
[20070126]

Will you please confirm whether the system can be shutdown if the 4764b68405ac918e9ac9939b1a2d1469102e5af7 commit is reverted?

Please attach the output of acpidump.
Thanks.

4764b68405ac918e9ac9939b1a2d1469102e5af7 is NOT the first bad commit, I'm really sorry. I tested it and it is good. I'm having a lot of problems bisecting because of boot kernel panics on some commits after this one.
I'm going to post acpidump of 2.6.26-rc3
Sorry again.

Created attachment 16281 [details]
acpidump of 2.6.26-rc3 (problem is present)

Hi, Riccardo
    From the description it is a regression. But there is no change about the ACPI shutdown. When the shutdown command is executed, the ACPI_power_off function will be called to shutdown the system, in which the content of _S5 object will be written into the PM1_CNT hardware register. And the next shutdown is controlled by  BIOS/hardware.
    Will you please double check whether the system can be shutdown correctly on the kernel of 2.6.25? (Had better the two kernels use the same config file).
    It will be great that you use the git-bisect to find which commit causes the regresssion.
    Please attach the following output.
    acpidump --addr 0xfdf00 --length 0x100 -o fseg
    Thanks.

Will you please check whether there exists the following error message on the kernel of 2.6.25? 
>r (psparse-0537): Method parse/execution failed [\ISMI] (Node f7c18630), 
AE_NO_MEMORY
>ACPI Error (psparse-0537): Method parse/execution failed 
>[\_SB_.PCI0.PX40.MIDI._STA] (Node f7c1ef68), AE_NO_MEMORY
>ACPI Error (exregion-0164): Could not map memory at F7C218943FFFFF00, size 200 
[20070126]

Please attach the output of dmesg on the kernel of 2.6.25 and 2.6.26-rc1?
Thanks.

Hello, I tried hard to bisect the kernel for three days but I never managed to complete a bisection because of kernel panics.
I used 2.6.25 a lot and I never experienced problems nor ACPI errors with it. I'll post the requested outputs on saturday.
Thanks.

can you try to build a kernel with minium driver and test if shutdown works with it?

Created attachment 16348 [details]
dmesg of 2.6.25.4

Created attachment 16349 [details]
2.6.26_rc1 dmesg (problem is present)

The command:
# acpidump --addr 0xfdf00 --length 0x100 -o fseg
produce no output using version 20061130.

I'm using always the same .config file (except new options) using make oldconfig.
I can confirm that 2.6.25(.1,.2,.3,.4) shutdown well and do not give ACPI errors, and 2.6.26_rc(1,2,3,4) doesn't shutdown.

Hi, Riccardo
    Thanks for the info.
    It seems that there are a lot of ACPI error messages in the dmesg of 2.6.26-rc1 and the problem occurs in the ISMI function.
   > ACPI Error (exregion-0164): Could not map memory at 000000003FFFFF00, size 200 [20080321]
  > ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for [SystemMemory] [20080321]
  > ACPI Error (psparse-0530): Method parse/execution failed [\ISMI] (Node f7c18630), AE_NO_MEMORY
  > ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.PX40.FDC0._STA] (Node f7c1ebd0), AE_NO_MEMORY
  > ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.PX40.FDC0._STA] (Node f7c1ebd0), AE_NO_MEMORY

    The definition of ISMI in bios is listed in the following:
 >    Method (ISMI, 1, Serialized)
    {
  >      Store (Arg0, TRTY) 
  >     Store (0xA7, SMCM)  }
    TRTY is defined in ACPR NVS memory region and the start address of ACPR memory region is defined in OperationRegion (FSEG, SystemMemory, 0x000FDF00, 0x0100)
    It seems that the ACPR memory region can't be mapped correctly, which causes that TRTY can't be accessed correctly.
    
    From the dmesg log we can know that the start address of ACPR memory region is 0x3FFFFF00 and region size is 0x200.
    > OperationRegion (NVSR, SystemMemory, ACPR, 0x0200)
    It seems that the memory region is beyond the ACPI NVS memory region.
      >BIOS-e820: 000000003fffc000 - 000000003ffff000 (ACPI data)
      >BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
    
    But it is very strange that the system can work well on the kernel of 2.6.25.
    
    Will you please use the latest acpidump tool to get the following output as required in comment #10?
   The latest dump tool(pmtool-20071116) can be found in:
   http://www.lesswatts.org/patches/linux_acpi/   
    

Hello,
the output of the new version of acpidump is the same of the one i attached, and unfortunately the command:
# acpidump --addr 0xfdf00 --length 0x100 -o fseg
produced no output also with pmtools-20071116 on a 2.6.26_rc1.

I can confirm that kernel 2.6.25.x works well. I also tried with a minimal kernel configuration without success.

Riccardo,
Perhaps you can limit the bisect to drivers/acpi,
than the whole kernel tree?

I believe that all the intermediate changes under drivers/acpi
should at least boot:-)

Re: acpidump
"-o fseg" should write a file called "fseg" -- is it empty?
if you omit that parameter, do you get anything to standard output?

Sorry about acpidump, I didn't think about -o meaning... -_-' I'll post the real output on saturday as usual.
Thanks and sorry again

2.6.26-rc5 works well, thank you!