Bug 6269
Summary: | bttv stops working after software suspend | ||
---|---|---|---|
Product: | Power Management | Reporter: | Markus Henschel (markus-henschel) |
Component: | Hibernation/Suspend | Assignee: | Rafael J. Wysocki (rjwysocki) |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | low | CC: | bunk, chiemera, mchehab, pavel, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.16 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 7216 | ||
Attachments: | bttv resume fix |
Description
Markus Henschel
2006-03-22 05:12:32 UTC
Created attachment 8863 [details]
bttv resume fix
The bttv resume tests seems to be wrong, since all errors, in kernel have
negative values. Can you test this patch?
Can you try the patch below? Sorry, I've been quite busy lately. I'll give it a try this evening when I come home. The patch doesn't work. I did some more research. As you said kernel errors are <0. So I changed in bttv_suspend: /* save pci state */ pci_save_state(pci_dev); -if(0!=pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state))) { +if(0<=pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state))) { pci_disable_device(pci_dev); btv->state.disabled = 1; + printfk("bttv device disabled\n"); } +else + printk("bttv device disabling failed :-(\n"); This revealed that setting the power state of the device when hibernating didn't work as dmesg contained: "bttv device disabling failed :-(" So btv->state.disabled is still zero when resuming. For this reason when entering bttv_resume pci_enable_device is not called. After that pci_set_power_state fails and btv->state.disabled is set to 1 again and the function is left without calling the chip initialization code futher down. The main reason for all this seems to me the calls to pci_set_power_state. They fail. The funny thing is that all these call seem to be completely unneccessary on my system. Is your x86_64 cpu dual-core? If so, it may be related to a bug on cpu hotplug, as bug #7786. On this case, you should try the patch http://bugzilla.kernel.org/attachment.cgi?id=10025&action=view No, it's a single core. What is the current status of this bug? The last applied patch didn't work for me but I had no time to test the issue against current kernel versions. The problem still persits with 2.6.20.: [ 198.736000] bttv0: Can't enable device. [ 198.736000] Bt87x 0000:01:08.1: resuming [ 198.736000] PM: Writing back config space on device 0000:01:08.1 at offset f (was ff040100, writing ff040105) [ 198.736000] PM: Writing back config space on device 0000:01:08.1 at offset 4 (was 8, writing fdffe008) [ 198.736000] PM: Writing back config space on device 0000:01:08.1 at offset 3 (was 800000, writing 802000) [ 198.736000] PM: Writing back config space on device 0000:01:08.1 at offset 1 (was 2800000, writing 2800006) [ 198.736000] ACPI: PCI Interrupt 0000:01:08.1[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 20 ... [ 199.784000] bttv0: timeout: drop=0 irq=9988/23456, risc=37832000, bits: VSYNC HSYNC OFLOW VPRES GPINT FBUS SCERR [ 199.784000] bttv0: reset, reinitialize [ 199.784000] bttv0: PLL: 28636363 => 35468950 .. ok [ 199.904000] bttv0: SCERR @ 37832000,bits: VSYNC HSYNC FBUS SCERR* [ 200.064000] bttv0: SCERR @ 37832000,bits: VSYNC HSYNC FBUS SCERR* [ 200.224000] bttv0: SCERR @ 37832000,bits: VSYNC HSYNC FBUS SCERR* [ 200.316000] bttv0: timeout: drop=0 irq=9993/23461, risc=37832000, bits: VSYNC HSYNC FBUS [ 200.316000] bttv0: reset, reinitialize [ 200.316000] bttv0: PLL: 28636363 => 35468950 . ok [ 200.424000] bttv0: SCERR @ 37832000,bits: VSYNC HSYNC FBUS SCERR* [ 200.584000] bttv0: SCERR @ 37832000,bits: VSYNC HSYNC FBUS SCERR* [ 200.744000] bttv0: SCERR @ 37832000,bits: VSYNC HSYNC FBUS SCERR* [ 200.832000] bttv0: timeout: drop=0 irq=9998/23466, risc=37832000, bits: VSYNC HSYNC FBUS [ 200.832000] bttv0: reset, reinitialize ... Markus, can you please try 2.6.22-rc5 and see if problem is still there. Thanks. Markus, please try 2.6.23 and see if the problem is still present. [If there's no reponse within two weeks, I'm going to close this entry.] Hi there, sorry for the delay. I don't had the time to reproduce the bug for 2.6.23 but for 2.6.20 it is still present. Currently I cannot afford to run a cutting edge kernel on this machine as I just have to do work on it but will do if time permits. I tested with 2.6.22-14 (ubuntu generic x86). The issue seems to be solved so this bug can be closed. |