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 | ||
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. |
Most recent kernel where this bug did not occur: 2.6.16 Distribution: Gentoo x86_64 and i686 Hardware Environment: Hauppauge BT878 Card, nForce4 Board, PCIe NVidia6800, 1GB Memory, nv xorg driver Software Environment: Xorg 6.8.2 Problem Description: When going to software suspend the bttv modules fails to work after waking up. When a TV app is running and accessing /dev/video0 the driver prints: "bttv0: Can't enable device." and continuous messages about timeouts. Steps to reproduce: 1. Start X 2. start a tv application (i.e. xawtv) 3. start a console and do "echo disk > /sys/power/state" 4. power on again, X11 and xawtv are restored I have got another box that runs kernel 2.6.11.11 and the same tv-card works fine after suspending so I compared the bttv-driver.c of 2.6.11 to 2.6.16. The relevant part seems to be: /////////////////////////////////////////////////////////////////////7 static int bttv_resume(struct pci_dev *pci_dev) { struct bttv *btv = pci_get_drvdata(pci_dev); unsigned long flags; int err; dprintk("bttv%d: resume\n", btv->c.nr); /* restore pci state */ if (btv->state.disabled) { err=pci_enable_device(pci_dev); if (err) { printk(KERN_WARNING "bttv%d: Can't enable device.\n", btv->c.nr); return err; } btv->state.disabled = 0; } err=pci_set_power_state(pci_dev, PCI_D0); if (err) { pci_disable_device(pci_dev); printk(KERN_WARNING "bttv%d: Can't enable device.\n", btv->c.nr); btv->state.disabled = 1; return err; } .... ///////////////////////////////////////////////////////////////////////////// When I comment out both "return err;" the device is working fine after resuming because the chip bttv chip initializing code after it is called. It's even working when commenting out the pci bus stuff completely. But I have no idea if this is only true for my system.