Bug 140257
Summary: | writing to /proc/acpi/sleep closes shell | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ben Liblit <liblit> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | intel-linux-acpi, pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-12-28 03:12:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 165150 |
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you. The bug still occurs exactly as originally described using Fedora Core 3 and kernel-2.6.11-1.14_FC3. After you resume, do you see any oops in dmesg? Please search upstream bugzilla.kernel.org for anything similar, if nothing exists file your own bug there and report here the URL. I see no oops in dmesg after resume. Among new dmesg output after resume, I do see the the following seemingly input-related messages: atkbd.c: Unknown key pressed (translated set 2, code 0x63 on isa0060/serio0). atkbd.c: Use 'setkeycodes 63 <keycode>' to make it known. Not sure if that's relevant. In any case, no oops. Although I see no oops, I do see kernel diagnostic output about a "sleeping function called from invalid context". That issue has already been reported as bug 140254. See <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140254#c2> for the complete diagnostic output. Note that this output includes syscall_call() which in turn calls sys_write(). Could this be the write system call being run by the "echo" command? Since "echo" is a shell built-in, if hte kernel decided to kill the process doing the write, that would actually kill the entire shell. Warren, do you think bug 140254 is sufficient to explain the shell-closing problem reported here? If so, we can mark this as a duplicate. If not, then I'll go ahead and report this as a distinct issue in the upstream kernel bugzilla as you originally requested. Bug 140254 is not sufficient to explain this, because exactly that happens to me on my IBM Thinkpad T41 and nothing happens to my shell after resume. Reported to upstream Linux Kernel Bugzilla as requested: <http://bugzilla.kernel.org/show_bug.cgi?id=4532>. An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. The problem still occurs using the latest 2.6.12-1.1398_FC4 kernel on my ThinkPad X40. I do have a minor additional clue, though: The shell only closes when using "zsh" as root's shell. If I change to "sh" first, the shell does not close. However, the shell does react as though an additional newline had been typed. I.e.: sh-3.00# echo 3 >/proc/acpi/sleep sh-3.00# sh-3.00# The second blank prompt there suggests that the shell thinks someone pressed <Enter> again after the echo command. At least once while testing this, though, the shell got into a bad loop where it would wake up and almost immediately go back to sleep again. I could even see extra "echo 3 >/proc/acpi/sleep" commands at the shell prompt each time. So this time it was as though the shell were repeatedly seeing <Up> followed by <Enter>, where <Up> was bringing the echo command back from the shell's command history and <Enter> was running the command again. The only way I could break out of this sleep loop was to race against the system to close root's shell (<Control>-D) before the echo command could be received yet again. Also, on just one occasion, when I pressed <Control> in order to start typing <Control>-D, the terminal window displayed its popup menu as though I'd pressed the right mouse button or perhaps some keycode which is mapped to <Menu> by the X server. This is all consistent with the general idea that junk is appearing in the input stream. I guess different shells with different command line editing setups react differently to that junk. Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks. Bug still manifests as originally described. However, the good news is that the upstream kernel bug (http://bugzilla.kernel.org/show_bug.cgi?id=4532) is marked RESOLVED/CODE_FIX, meaning that "A patch has been created and is awaiting approval by the appropriate kernel maintainer or Linus Torvalds." 2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you. Patch is merged in current updates. Assuming fixed. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Epiphany/1.2.7 Description of problem: With ACPI enabled, I can put my ThinkPad X24 laptop to sleep (S3) and wake it back up again. However, if I used the very simple "echo 3 >/proc/acpi/sleep" technique to sleep, my root shell is closed by the time the laptop resumes. It appears that several newlines and an EOF are arriving on my pseudo-TTY from ... well ... from I have no idea where. Version-Release number of selected component (if applicable): kernel-2.6.9-1.3_FC2 How reproducible: Always Steps to Reproduce: Two choices: 1. Log in to the text console as root. Or if you prefer, start a terminal window and "su" to root. 2. Type "echo 3 >/proc/acpi/sleep". 3. Wake the computer back up. Actual Results: If you had logged in to the text console as root, you are no longer logged in. You're simply back to the "login:" prompt. Furthermore, a NULL control character ("^@") is visible as though it had been typed in at the "login:" prompt. If you had used "su" to become root, your root shell is no longer running. There are several blank lines below the "echo" command you typed, and then several blank prompts in the shell from which you typed "su". It appears as though the terminal window received (as input) a number of newlines with an EOF stuck in the middle somewhere. Expected Results: Sleeping and waking up should not generate any "phantom" input. The shell that did the write should come back in exactly the state we left it: still logged in, or still su'ed to root. Additional info: