Bug 8532 - RESET on poweroff if Adaptec present
RESET on poweroff if Adaptec present
Product: ACPI
Classification: Unclassified
Component: Power-Off
i386 Linux
: P2 blocking
Assigned To: Zhang Rui
Depends on:
  Show dependency treegraph
Reported: 2007-05-24 02:53 UTC by Ian Walker
Modified: 2008-07-07 23:56 UTC (History)
1 user (show)

See Also:
Kernel Version: Ubuntu kernel 2.6.20-15
Tree: Mainline
Regression: ---

dmesg normal (18.66 KB, text/plain)
2007-06-01 04:08 UTC, ChenYongqiang
use acpi=off apm=on power-off=apm (16.75 KB, text/plain)
2007-06-01 04:09 UTC, ChenYongqiang
hardware info (1.94 KB, text/plain)
2007-06-01 04:39 UTC, ChenYongqiang
config- (69.17 KB, application/octet-stream)
2007-12-11 11:50 UTC, Ian Walker
config- (37.59 KB, text/plain)
2007-12-14 13:43 UTC, Len Brown

Description Ian Walker 2007-05-24 02:53:34 UTC
Most recent kernel where this bug did *NOT* occur:

Mandriva Linux 2006 (2.6.12.x kernel)

Hardware Environment:

Gigabyte GA-7VTXE motherboard (F7 BIOS since F8 and F9 are unsuitable for my
machine and don't work as they should), AMD Athlon XP 1800+, 1GB RAM, 2 x 160GB

Software Environment:

Ubuntu 7.04 Feisty

Problem Description:

The machine never shuts down, it always resets.  I was told using acpi=off
apm=on apm=power-off would resolve the problem, but it seems that this doesn't
do it for me.

Steps to reproduce:

All distributions I have used since Mandriva 2006, that have been using a kernel
higher than 2.6.17.x.  I've not known a distro with a kernel in between 2.6.12.x
which worked, and 2.6.17x that I could test.
Comment 1 ChenYongqiang 2007-05-29 18:10:51 UTC
I hava the same problem! When i use kernel 2.6.20.x and 2.6.21.x my notebook 
poweroff instead by reboot!  
I must use the "acpi=off apm=on apm=power-off" parameters too!!

I will post my dmesg and hardware information for a moment!
Comment 2 ChenYongqiang 2007-06-01 04:08:02 UTC
Created attachment 11634 [details]
dmesg normal

Comment 3 ChenYongqiang 2007-06-01 04:09:42 UTC
Created attachment 11635 [details]
use acpi=off apm=on power-off=apm
Comment 4 ChenYongqiang 2007-06-01 04:39:41 UTC
Created attachment 11637 [details]
hardware info
Comment 5 ChenYongqiang 2007-06-02 17:45:42 UTC
Why nobody to see this bug?? 
Comment 6 Ian Walker 2007-06-03 22:56:55 UTC
That's what I was wondering.

Incidently your suggestion of:

acpi=off apm=on power-off=apm

doesn't work for me.  So there is definitely a kernel bug, yet nobody is
bothering to action the bug.
Comment 7 ChenYongqiang 2007-06-04 01:20:57 UTC
My notebook does't poweroff since upgrade kernel to 2.6.2x!

I try compile all of the 2.6.2x version kernel, but problem still exist!

"It often poweroff instead by reboot!"

Help me!!
Comment 8 Zhang Rui 2007-06-04 19:08:03 UTC
Hi, Ian:
Do you mean the "poweroff" never works on your laptop?
Please test the latest kernel release, and attach the _dmesg_ output without 
any boot parameters.

to Yongqiang:
It seems that you running a MP kernel on a UP platform, please try the boot 
parameter "noapic".
>ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r1 C-state control [20070126].
Don't know if it's related. You'de better upgrade your bios first. :)
Comment 9 ChenYongqiang 2007-06-05 17:39:36 UTC
It can't boot if no "noapic" parameter was added when installing fedora7 by grub!

But when i select harddisk install from my usb removable disk, kernel appear

apic error, i  could't get the error message!
Comment 10 Ian Walker 2007-06-06 00:03:43 UTC
I'm not using a laptop, but my machine never powers off, and it doesn't matter
if it's a new kernel or not.  Ever since 2.6.12.x kernel, it hasn't worked.
Comment 11 Zhang Rui 2007-06-08 01:40:11 UTC
Hi, Yongqiang

>ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r1 C-state control [20070126]
This is from the "dmesg normal".
It shows the potential risks of running this bios with ACPI enabled.
Please try the latest bios firtst.:)

>It can't boot if no "noapic" parameter was added
> when installing fedora7 by grub!
Do you mean your kernel can not boot with the parameter "noapic"?
Comment 12 ChenYongqiang 2007-06-10 19:34:09 UTC
No! When i normal install fedora7, my laptop was stopping when kernel booting!
When i install from grub with noapic parameter, above circs disappeared, but when
i use the usb removable disk, the kernel appear apic error!

Sorry, my english is bad!
Comment 13 Ian Walker 2007-06-13 06:30:29 UTC
Anyone got anywhere with this?  It should be something simple to resolve since it was working in a 2.6.12.x kernel.
Comment 14 ChenYongqiang 2007-08-10 00:12:09 UTC
I try the 2.6.22, but the problem is still exist!

My laptop doesn't poweroff, just resets!

My BIOS version is KN2 3A71, why??

Need another hardware informations or logs???
Comment 15 Ian Walker 2007-08-22 05:40:33 UTC
I found that if I remove my Adaptec Ultra 160 AIC-7892 SCSI card, the machine will power off.  It's something related to this that causes it to reset rather than power down.
Comment 16 Fu Michael 2007-10-10 01:13:23 UTC
Ian, would you please try to remove the driver module for the Adaptec SCSI adapter and retry to see if your machine can successfully shutdown? ( not physically remove the card from the machine.)

yongqiang, please open another bug for your issue. it's likely not related with Ian's bug.
Comment 17 Ian Walker 2007-10-18 05:11:24 UTC
I have tried this but it doesn't work.  The card has to be physically removed from the machine.

I did:

modprobe -r aic7xxx

and then checked.  I also blacklisted the module from loading and restarted the machine with same result - it didn't shut down properly.
Comment 18 Fu Michael 2007-10-25 02:17:46 UTC
Ian, how about the solution in bug# 6712?
Comment 19 Ian Walker 2007-10-26 15:17:55 UTC
This is probably going to sound like a stupid question, but can I just edit
the /boot/config file and change CONFIG_ACPI_SLEEP=y to CONFIG_ACPI_SLEEP=n
or do I have to recompile kernel?
This is probably going to sound like a stupid question, but can I just edit the /boot/config file and change CONFIG_ACPI_SLEEP=y to CONFIG_ACPI_SLEEP=n or do I have to recompile kernel?<br>
Comment 20 Zhang Rui 2007-10-28 18:20:51 UTC
Hi, Ian,
You need to modify your own kernel config file, not the one /boot/config-2.6.xx and recompile kernel.
Comment 21 Ian Walker 2007-11-05 12:34:11 UTC
I'm trying to do this with kernel- but I cannot find the option to disable CONFIG_ACPI_SLEEP.

I've tried editing /usr/src/linux- but each time I make the kernel, it resets it.  I've even searched when using "make menuconfig" and I cannot find it anywhere to disable it.

Let me know where I need to find it so I can try it.
Comment 22 Len Brown 2007-12-06 20:13:19 UTC
as of 2.6.23
are necessary to disable PM_SLEEP and ACPI_SLEEP,
which are now internal-only config options,
not features selected by the user.

Since this failure happens only with the Adaptec present,
it is probably due to some side effect of trying
to poweroff that device, or somehow that device
is provoking an immediate S5 wake event.

Comment 23 Fu Michael 2007-12-09 18:53:52 UTC
Ian, can you follow Len's suggestion and re-test?
Comment 24 Ian Walker 2007-12-09 23:59:56 UTC
I have done:

make menuconfig

but can't see the options to turn off, just like last time.  So if I can't disable them here, how can I disable them?

Tell me how?  Until I know, I cannot test.  I asked this back in #21.  Internal-only config options doesn't tell me where I need to disable it.
Comment 25 Fu Michael 2007-12-10 17:24:55 UTC
(In reply to comment #24)
> I have done:
> make menuconfig
> but can't see the options to turn off, just like last time.  So if I can't
> disable them here, how can I disable them?
> Tell me how?  Until I know, I cannot test.  I asked this back in #21. 
> Internal-only config options doesn't tell me where I need to disable it.

Ian, would you please attach your kernel config file then?
Comment 26 Ian Walker 2007-12-11 11:50:59 UTC
Created attachment 13977 [details]

Kernel config file.
Comment 27 Len Brown 2007-12-14 13:43:56 UTC
Created attachment 14042 [details]

Here is a 2.6.23 .config with SUSPEND and HIBERNATION disabled.
I created it from the previous attachment by editing the file
and running "make oldconfig".  (I don't use menuconfig, but
if this was impossible to do with menuconfig, that would
certainly also be an additional issue)
Comment 28 Len Brown 2008-01-13 23:52:31 UTC
is this still an issue with 2.6.24?
Comment 29 Ian Walker 2008-01-14 09:55:06 UTC
I've tried with and it doesn't work with this.  Has there been any major changes since that would hint at 2.6.24 working?  Because I don't think it will.

The only thing that solves it is taking the Adaptec card out.
Comment 30 Len Brown 2008-01-14 22:01:20 UTC
I don't know of anything in particular in 2.6.24 that would help,
just that we've been waiting for an answer to the question
in comment #27 for month and 2.6.23 is becoming less interesting.

can you test 2.6.23 with the .config produced in comment #27?
Comment 31 Ian Walker 2008-01-15 10:33:03 UTC
Yes, what with Christmas and everything, compiling a kernel was least of the things on my mind.

However, I have compiled without suspend and resume and it doesn't work.  That is what I just said in #29.
Comment 32 Ian Walker 2008-01-17 06:49:02 UTC
Also, relating to comment #24, where can I download 2.6.24 since it doesn't seem to exist at kernel.org?!?  That would kind of make it a little hard for me to use.

I'm wondering whether to pursue this any further, since we seem to be clutching at straws and nothing seems to be solving it.  What other information can I simply provide you with that might actually resolve this.

As I mentioned before a 2.6.12.x kernel worked perfectly fine, so in terms of my usage, this problem has existed in every kernel release since and this bug was highlighted from 2.6.17.x kernels and we're no further forward some 7 kernel releases later (not including point releases).  To me, the problem lies between the Adaptec card and ACPI - at least this is clear to me.

Maybe I should just forget about it and "live" with it and either use:


on the kernel line and then press and hold my power button for five seconds or so just after the last message I receive that says my system has halted.  Or, just remove the Adaptec card and have the system shut down successfully.
Comment 33 Ian Walker 2008-01-17 06:49:54 UTC
Sorry, meant comment #28 not #24 in previous update.
Comment 34 Len Brown 2008-01-17 12:28:42 UTC
I suspect that the system may actually reach power-off,
but that the Adaptec card is pulling on PME# or something
and immediately waking up the system.

When you build with CONFIG_ACPI_DEBUG=y,
what is the last thing printed on the console before the "reset"?
(if the VGA goes out before you can see it, you can use a serial
 console to preserve it, or we can insert forever loops in the
 poweroff path to see if you really make it to the end)

Please attach the output from lspci -vv
when the Adaptec card is present.  It will tell us about PME.

Also, check if there are any wakeup settings in the BIOS SETUP,
or PCI settings in the Adaptec BIOS menus.

re: 2.6.24
it is currently in -rc8, which you can get here:
or via git, as described here re the "linus" tree:

> acpi=off and power button press as a workaround

I think that booting with ACPI enabled and using "halt"
instead of "poweroff" should give you the same result.
It would avoid the reboot issue, but would require you to
press (and hold) the power button to remove power.
Comment 35 Ian Walker 2008-01-18 07:37:52 UTC
We are kind of getting somewhere.

I booted with today, after re-compiling with CONFIG_ACPI_DEBUG=y as you mentioned.  I wasn't really getting any extra input at the end of the process.  I typed "halt" and then it would just sit and wait for a power off, like when I was adding acpi=off to kernels that wouldn't shut my machine down, and just reboot instead.  However, I then noted your last comment of "using halt instead of poweroff".

So I thought I would type "poweroff" instead of "halt".  When I did this, the machine powered off properly.  However, it would only do this on the kernel with SUSPEND and HIBERNATE disabled.  If I tried it with the generic CentOS 5 kernel, it would just reboot as it was doing previously.

Here is the lspci -vv for the Adaptec card:

00:0b.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02)
        Subsystem: Adaptec 19160 Ultra160 SCSI Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (10000ns min, 6250ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 177
        BIST result: 00
        Region 0: I/O ports at dc00 [disabled] [size=256]
        Region 1: Memory at dffff000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at dffc0000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

will that lspci output help in some way to allow SUSPEND and HIBERNATE to co-exist with the Adaptec module than to have it disabled and removed like we have done so far?  The module is aic7xxx.
Comment 36 Ian Walker 2008-01-18 07:51:19 UTC
I forgot to mention that /sbin/poweroff is a symlink to /sbin/halt.  So that wouldn't explain why poweroff works and halt doesn't.

However, there is a /usr/bin/poweroff as well, which is symlinked to /usr/bin/consolehelper.

When I tested, I logged in as root, therefore the sbin path statement was before /usr/bin.  So it must have called /sbin/poweroff which is really /sbin/halt.  So I don't know why poweroff worked and halt didn't.
Comment 37 Ian Walker 2008-02-02 00:44:26 UTC
Any ideas of if whether a fix will be incorporated into the kernel for the bug between acpi and aic7xxx or not?

Or will it just be left as a case of disabling CONFIG_SUSPEND and CONFIG_HIBERNATE thus meaning that suspend or hibernate cannot be used?
Comment 38 Ian Walker 2008-02-12 00:17:25 UTC
Does anyone have an update on the status of this?
Comment 39 Ian Walker 2008-02-12 23:44:42 UTC
Is there any update?  Is anything being done?
Comment 40 Ian Walker 2008-02-21 15:51:32 UTC
So, it's over a month and nobody can be bothered to put an update as to what is happening?  Is someone actually doing anything, or should I just forget about this since it seems no-one is interested.
Comment 41 Ian Walker 2008-02-22 07:56:18 UTC
Any update?
Comment 42 Ian Walker 2008-02-22 16:59:00 UTC
Anyone working on this or not?
Comment 43 Ian Walker 2008-02-25 00:46:23 UTC
Is someone working on this, or has it been put to the back of the queue?  An update would be appreciated than it just going ignored.

Although, if it is going to get ignored, then you may as well just delete it then if it's going to be ignored.

Funny how people are pushed to log bugs to get a fix to help improve Linux, and then yet we find nothing seems to be being done about them.  Ah well, such is life I suppose.
Comment 44 Roland Kletzing 2008-03-31 12:44:12 UTC
>Funny how people are pushed to log bugs to get a fix to help improve Linux, 
>and then yet we find nothing seems to be being done about them.  Ah well, 
>such is life I suppose.

Ian, it`s probably because not all kernel devs scan bugzilla daily/weekly and it`s because kernel devs are very busy people and you simply can`t expect them to spend significant time to solve your very specific problem. 

i think you got already got a LOT of help here!

>As I mentioned before a 2.6.12.x kernel worked perfectly fine, so in terms 
>of my usage, this problem has existed in every kernel release since and 
>this bug was highlighted from 2.6.17.x kernels and we're no further forward 
>some 7 kernel releases later (not including point releases).  To me, the
>problem lies between the Adaptec card and ACPI - at least this is clear to me.

you could help finding what`s the issue by finding the last kernel release which works and the first kernel release which failed. 

that should be straightforward and doesn`t take much time (besides compile time of your computer) 

the best and shortest way to find that kernel is using "git bisect" - but you may find some time to get used to it.

Comment 45 ykzhao 2008-04-22 00:41:37 UTC
Hi, Ian
    Will you please try the latest kernel and see whether the problem still exists? 
    Please attach the output of acpidump, lspci -vxxx.
Comment 46 Ian Walker 2008-04-23 06:05:51 UTC
Thanks for the reply.

Has something been changed in the recent release regarding ACPI and Adaptec AIC7890 SCSI (aic7xxx) module?

If something hasn't been changed based on the information of this bug report then I'm not willing to try a new kernel.  Too many times I've been downloading and trying new kernels and nothing has changed in any of these relating to my problem.

I'd prefer if the issue was addressed, rather than for me to download a try a new kernel in the hope it *might* solve my problem.

Appreciate the help, but I've endlessly downloaded new kernels and nothing has happened.  Confirmation that something had been done in version x.x.x.xx kernel and please try this kernel and let us know, would be better.

If not, then I'm happy to close the bug and just live with it because I don't have time to keep testing all the time if we're not actually getting anywhere with the results I've provided so far.

Comment #35 has lspci information.  Comment #36 shows what works and what didn't for initiating a successful shutdown.
Comment 47 ykzhao 2008-04-28 01:07:22 UTC
Hi, Ian
   Understand what you said in comment #46. And I agree with what Len said in comment #34. The system may actually reach power-off, but the PME# of the adaptec card immediately wake up the system again.
   Will you please confirm whether the system can be power-off correctly on windows?
Comment 48 Ian Walker 2008-04-28 02:38:25 UTC

When I last had Windows on the machine it was perfectly fine.  Also when Mandriva 2006 with 2.6.12.x kernel was installed, it was also fine.  Just that anything after this is an issue.

Comment #35 and #36 show how I managed to get the system to shut down with newer kernels, but don't understand why one command worked and one didn't when they were symlinked to the same command.  Of coure, this only happens when CONFIG_ACPI_SUSPEND and CONFIG_ACPI_HIBERNATE are disabled.

Whilst this machine isn't requiring SUSPEND and HIBERNATE, it can be lived with.  It just means that I would need to ensure that I use my own kernels and not distro-specific ones. My main idea was that if we could get this to work, I could use distro-specific kernels without having to roll my own each time.

However, I do also acknowledge that this computer is seven years old now, so perhaps with the same card in a new machine that this problem might not even exist!  I will replace this machine sometime within the next year or so, so can also survive with manually compiled kernels for the time being.  And always create a new bug later for the new machine should it follow across.
Comment 49 ykzhao 2008-05-04 03:07:44 UTC
Hi, Ian Walker
    Will you please try the debug patch in comment five of bug 10503 and see whether the system can be power off? 
Comment 50 Ian Walker 2008-05-05 01:10:09 UTC

This is weird, because this weekend we had a power cut whilst my computer was on.  When I switched my computer back on again, I was able to shut it down completely without any modifications on the system.

I tried it again to make sure it wasn't just a one-off, and it is definitely working normally.  It has been each and every time I've booted and shut the computer down since.

I don't know what the power cut did, but it did something.  All my hardware is working fine, including the scsi card which seemed to be the link in causing this problem.
Comment 51 ykzhao 2008-05-05 02:17:35 UTC
Hi, Ian
    It seems that your computer can be shutdown correctly after power cut. It looks very weird. Since the bug can't be reproduced on your desktop, IMO this bug can be rejected.
    If the problem still exists, please reopen it.
Comment 52 Ian Walker 2008-05-05 04:59:14 UTC
Yes, have to agree with you on that - since I don't know why this happened now - and wanted to get to the bottom of it to find out exactly what caused the issue.

Note You need to log in before you can comment on or make changes to this bug.