Bug 6269

Summary: bttv stops working after software suspend
Product: Power Management Reporter: Markus Henschel (markus-henschel)
Component: Hibernation/SuspendAssignee: Rafael J. Wysocki (rjwysocki)
Severity: low CC: bunk, chiemera, mchehab, pavel, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16 Tree: Mainline
Regression: Yes
Bug Depends on:    
Bug Blocks: 7216    
Attachments: bttv resume fix

Description Markus Henschel 2006-03-22 05:12:32 UTC
Most recent kernel where this bug did not occur: 

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 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:

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) {
		if (err) {
			printk(KERN_WARNING "bttv%d: Can't enable device.\n",
			return err;
		btv->state.disabled = 0;
	err=pci_set_power_state(pci_dev, PCI_D0);
	if (err) {
		printk(KERN_WARNING "bttv%d: Can't enable device.\n",
		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
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 */
-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))) {
    btv->state.disabled = 1;
+   printfk("bttv device disabled\n");
+   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
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.
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.