On Mon, Jul 03, 2006 at 04:21:09PM -0700, Greg KH wrote:
> When suspending, pci_save_state() would have saved off those values (all
> 1s) which is what it is restoring. That function gets called if there
> is no driver specific suspend function to call. On suspend, is there
> any driver loaded for the device?
No driver is loaded.
> And what type of PCI device is this?
It does for these devices:
01:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3)
01:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08)
01:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev
17)
01:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter
(rev 08)
01:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 03)
> Any chance you can test -mm and see if that helps with suspend/resume?
> Linus's new suspend framework is in there, and that's the way forward
> for these kinds of issues.
I found out, that pci_save_state() reads 0xffffffff value using
pci_read_config_dword for these devices. Actually, I modified pci_save_state
like this:
int
pci_save_state(struct pci_dev *dev)
{
int i;
/* XXX: 100% dword access ok here? */
printk(KERN_ERR "PM: Saving config space on device %s.\n",
pci_name(dev));
mdelay(500);
for (i = 0; i < 16; i++) {
pci_read_config_dword(dev, i * 4,&dev->saved_config_space[i]);
if(strcmp(pci_name(dev), "0000:01:01.4") == 0)
printk(KERN_ERR "PM: Saved value: %x.\n", dev->saved_config_space[i]);
}
if ((i = pci_save_msi_state(dev)) != 0)
return i;
if ((i = pci_save_msix_state(dev)) != 0)
return i;
return 0;
}
With this result in log:
kernel: PM: Saving config space on device 0000:01:01.4.
kernel: PM: Saved value: ffffffff.
last message repeated 15 times
So, looks like not enabled/mapped device returns 1s.
(For none of mentioned devices is loaded driver, so they are all disabled).
So for now, I disabled to restore state of value 0xffffffff and things go OK.
--
Lukáš Hejtmánek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]