lkml.org 
[lkml]   [2006]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectpci_restore_state
From
Date
Hello.

Currently pci_restore_state() (drivers/pci/pci.c) restores the PCI state
by copying in the saved PCI configuration space, a dword at a time,
starting from 0 up to 15.

This causes a crash when my Macbook resumes from sleep (specifically,
when restoring the configuration space of the PCI bridge).

Reading the PCI specification, the register at dword 1 (ie: bytes 4-7)
is split half and half between status and command words. The command
word effectively controls the way which the PCI device interacts with
the system. If it is 0, the device is logically disconnected from the
bus (PCI Local Bus Specification Revision 2.2, 6.2.2 "Device
Control").

When a device first powers up, the command register value is normally
zero (and is zero in my specific case).

The problem with the way that the PCI state is currently restored is
that the write to the command register logically reconnects the device
to the bus before the rest of the configuration space has been filled
in.

My Macbook crashes on resume.

If I reverse the for loop to start from 15 and count down to 0, then the
majority of the configuration space is filled in _before_ the command
word is modified. No crash.

About dword 0 -- this dword contains only the vendor and product ID
codes which will always be set by the device (as far as I know) so it's
not a problem to not have written these before restoring the value of
the command register. I'm not sure they even ever need to be written.

I am essentially requesting that this piece of code be changed in the
stock kernel as I changed it (described above). It makes sleep work on
my Macbook and may fix some others too (and/or make more reliable some
which already work).

Cheers
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-06-04 12:16    [W:0.045 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site