Bug 6269 - bttv stops working after software suspend
bttv stops working after software suspend
Status: CLOSED PATCH_ALREADY_AVAILABLE
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
i386 Linux
: P2 low
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2006-03-22 05:12 UTC by Markus Henschel
Modified: 2007-11-27 13:57 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.16
Tree: Mainline
Regression: Yes


Attachments
bttv resume fix (787 bytes, patch)
2006-08-23 15:14 UTC, Mauro Carvalho Chehab
Details | Diff

Description Markus Henschel 2006-03-22 05:12:32 UTC
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.
Comment 1 Mauro Carvalho Chehab 2006-08-23 15:14:26 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?
Comment 2 Pavel Machek 2006-09-29 04:19:50 UTC
Can you try the patch below?
Comment 3 Markus Henschel 2006-09-29 05:11:51 UTC
Sorry, I've been quite busy lately. I'll give it a try this evening when I come
home.
Comment 4 Markus Henschel 2006-10-02 13:57:02 UTC
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.
Comment 5 Mauro Carvalho Chehab 2007-01-22 16:54:28 UTC
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
Comment 6 Markus Henschel 2007-01-23 01:05:04 UTC
No, it's a single core.
Comment 7 Rafael J. Wysocki 2007-05-30 11:17:45 UTC
What is the current status of this bug?
Comment 8 Markus Henschel 2007-06-01 01:42:57 UTC
The last applied patch didn't work for me but I had no time to test the issue
against current kernel versions.
Comment 9 Markus Henschel 2007-06-21 15:54:21 UTC
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
...
Comment 10 Natalie Protasevich 2007-06-21 23:49:00 UTC
Markus, can you please try 2.6.22-rc5 and see if problem is still there.
Thanks.
Comment 11 Rafael J. Wysocki 2007-10-12 13:06:37 UTC
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.]
Comment 12 Markus Henschel 2007-11-04 04:56:41 UTC
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.

Comment 13 Markus Henschel 2007-11-27 13:57:18 UTC
I tested with  2.6.22-14 (ubuntu generic x86). The issue seems to be solved so this bug can be closed.

Note You need to log in before you can comment on or make changes to this bug.