Most recent kernel where this bug did *NOT* occur: Distribution: 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 IDE HDD 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.
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!
Created attachment 11634 [details] dmesg normal Normal!
Created attachment 11635 [details] use acpi=off apm=on power-off=apm
Created attachment 11637 [details] hardware info
Why nobody to see this bug??
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.
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!!
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. :)
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!
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.
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"?
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!
Anyone got anywhere with this? It should be something simple to resolve since it was working in a 2.6.12.x kernel.
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???
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.
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.
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.
Ian, how about the solution in bug# 6712?
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>
Hi, Ian, You need to modify your own kernel config file, not the one /boot/config-2.6.xx and recompile kernel.
I'm trying to do this with kernel-2.6.23.1 but I cannot find the option to disable CONFIG_ACPI_SLEEP. I've tried editing /usr/src/linux-2.6.23.1/.config 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.
Ian, as of 2.6.23 CONFIG_HIBERNATION=n CONFIG_SUSPEND=n 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.
Ian, can you follow Len's suggestion and re-test?
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.
(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?
Created attachment 13977 [details] config-2.6.23.9 Kernel config file.
Created attachment 14042 [details] config-2.6.23.9-nosleep 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)
is this still an issue with 2.6.24?
I've tried with 2.6.23.9 and it doesn't work with this. Has there been any major changes since 2.6.23.9 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.
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?
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.
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: acpi=off 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.
Sorry, meant comment #28 not #24 in previous update.
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: http://kernel.org/ or via git, as described here re the "linus" tree: http://www.lesswatts.org/projects/acpi/git.php > 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.
We are kind of getting somewhere. I booted with 2.6.23.9 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.
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.
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?
Does anyone have an update on the status of this?
Is there any update? Is anything being done?
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.
Any update?
Anyone working on this or not?
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.
>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. http://kerneltrap.org/node/11753 http://kernel.org/doc/local/git-quick.html
Hi, Ian Will you please try the latest kernel and see whether the problem still exists? Please attach the output of acpidump, lspci -vxxx. Thanks.
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.
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? Thanks.
Hi, 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.
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? Thanks.
Hi, 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.
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.
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.