Bug 146457
Summary: | Toshiba Tecra M2: panic after long APM suspend in cpufreq_resume -> set_rtc_mmss | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jesse Glick <typrase> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-03-06 16:53:39 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: |
Description
Jesse Glick
2005-01-28 14:59:08 UTC
This looks a whole lot like #144415. Yes, it does indeed, thanks for finding this! Still reproducible on same machine using stock kernel-2.6.10-1.766_FC3. *** This bug has been marked as a duplicate of 144415 *** Added note: I reproduced it today after unmounting all non-root FSs, unloading all possible kernel modules, and killing off most noncritical daemons (incl. cpuspeed and apmd but leaving X running in a GDM chooser), so I don't guess the problem is specific to some buggy running software outside the kernel. Note: appears that the root problem is something to do with the spin lock rtc_lock in arch/i386/kernel/time.c being misused, though I am not sure why this would be - it is used only from set_rtc_mmss() (cause of error here) and get_cmos_time(), both of which lock and unlock it with no other control flow. That said, there looks to be a secondary buglet in the panic handling: i8042.c:914 is in fact the i8042_panic_blink method and seems to be the line while (i8042_read_status() & I8042_STR_IBF) DELAY; // <-- HERE Apparently we are in_irq() at this point (see delay.h:32; confirmed by the stack trace) and mdelay() does not want to be called inside an IRQ. Meaning, I guess, that calling panic() from inside an IRQ was not a good idea, or that i8042_panic_blink is wrong to be using DELAY in this way, or something. |