On Wednesday, August 31, 2005 2:44 PM Greg KH wrote:
>>On Thu, Aug 18, 2005 at 01:35:46PM +0800, Shaohua Li wrote:
>> Hi,
>> It appears pci_enable_msi doesn't reconfigure msi registers if it
>> successfully look up a msi for a device. It assumes the data and
address
>> registers unchanged after cal
On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
> So what is the alternative to Shaohua's fix? Restore all the msi
> registers on resume?
Yes, the PCIe port bus driver, for example, did that.
Thanks,
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote:
>>
>> On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
>> > So what is the alternative to Shaohua's fix? Restore all the msi
>> > registers on resume?
>>
>> Yes, the PCIe port bus driver, for example, did that.
>>
> So y
On Thursday, September 01, 2005 10:38 PM Greg KH wrote:
>> Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64
bytes
>> of PCI header. One solution is to extend these APIs to cover up to
256
>> bytes. What do you think?
> Will that solve this issue?
Yes.
Thanks,
Tom
-
To unsubscrib
On Friday, March 11, 2005 11:28 PM Greg KH wrote:
>> +
>> +LIST_HEAD(evt_queue); /* Define Event Queue
List */
>
>Make this static?
Agree, will make this static. Good comment! Thanks.
>> +
>> +/**
>> + * evt_queue_pop - restore an event node from an event log list
>> + * @
Monday, March 14, 2005 3:01 AM David Vrabel wrote:
>> This patch includes PCIEAER-HOWTO.txt, which describes how the PCI
>> Express Advanced Error Reporting Root driver works.
>>
>> --- linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt
>>
>Could this be placed in a sub-system subdirectory (creating
On Saturday, March 12, 2005 2:27 PM Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - pci-acpi.c: make OSC_UUID static
> - remove the following unused functions:
> - pci-acpi.c: acpi_query_osc
> - pci-acpi.c: pci_osc_support_set
> - remove the following unneeded EXPORT
On Friday, March 11, 2005 11:25 PM Greg KH wrote:
>> +static ssize_t aer_sysfs_consume_show(struct device_driver *dev,
char >>*buf)
>> +{
>> +return aer_fsprint_record(buf);
>> +}
>> +
>> +static ssize_t aer_sysfs_status_show(struct device_driver *dev, char
>>*buf)
>> +{
>>
On Friday, March 11, 2005 11:21 PM Greg KH wrote:
>>
>> -Report the errors to user.
>>
>This is done through the syslog, right? Is that acceptable?
Reporting the errors to user can be written automatically to
/var/log/messages or be manually consumed through the syslog. I am not
sure whether
On Saturday, March 12, 2005 1:38 AM Andi Kleen wrote:
>I haven't read your code in detail, just a high level remark.
>
>> +6. Enabling AER Aware Support in PCI Express Device Driver
>> +
>> +To enable AER aware support requires a software driver to configure
>> +the AER capability structure within
On Friday, March 11, 2005 2:49 PM Paul Mackerras wrote:
>> The standard PCI Specification calls out SERR and PERR. I am not sure
>> about the recent discussion of PCI error of recovery. It is perhaps
>> regarding the possibility of recovering from a PERR or SERR. However,
>> PCI Express error occur
Friday, March 11, 2005 11:30 PM Greg KH wrote:
>> +
>> +LIST_HEAD(rc_list); /* Define Root Complex List */
>>
>Static?
The rc_list is not static. Thanks for pointing it out. Will make it
static.
Thanks,
Long
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Tuesday, March 15, 2005 12:12 PM Grant Grundler wrote:
>Tom,
>A co-worker made the following observation (I'm paraphrasing):
> ...this proposal does not deal with the Error Reporting ECN.
> For example, they do not show the advisory non-fatal bit in
> the correctable error stat
On Tuesday, March 15, 2005 2:38 PM Grant Grundler wrote:
>> >A co-worker made the following observation (I'm paraphrasing):
>> >...this proposal does not deal with the Error Reporting ECN.
>> >For example, they do not show the advisory non-fatal bit in
>> >the correctable error status r
Tuesday, March 15, 2005 2:51 PM Linas Vepstas wrote:
>> +void hw_aer_unregister(void)
>> +{
>> +struct pci_dev *dev = (struct pci_dev*)host->dev;
>> +unsigned short id;
>> +
>> +id = (dev->bus->number << 8) | dev->devfn;
>> +
>> +/* Unregister with AER Root driver */
>> +pci
On Wednesday, March 16, 2005 7:52 PM Paul Mackerras wrote:
>> We need some PCI
>> based error flows to understand the details of the flow so we can
>> develop an interface compatible with both.
>
>Here is a basic outline of what happens with EEH (Enhanced Error
>Handling) on IBM PPC64 platforms. T
On Wednesday, March 16, 2005 7:20 PM Benjamin Herrenschmidt wrote:
>> What mechanism (message??) is used to perform the bus and/or link
>> level reset? For PCI Express the reset is performed by the upstream
>> port driver. My API takes this into account. Are you assuming the
PCI
>> device on the
On Thursday, March 17, 2005 6:44 PM Benjamin Herrenschmidt wrote:
>I have difficulties following all of your previous explanations, I must
>admit. My point here is I'd like you to find out if the API can fit on
>the driver side, and if not, what would need to be changed.
In summary, we agreed that
On Thursday, March 17, 2005 8:01 PM Paul Mackerras wrote:
> Does the PCI Express AER specification define an API for drivers?
No. That is why we agree a general API that works for all platforms.
>Likewise, with EEH the device driver could take recovery action on its
>own. But we don't want to en
On Friday, March 18, 2005 10:10 AM Grant Grundler wrote:
>A port bus driver does NOT sound like a normal device driver.
>If PCI Express defines a standard register set for a bridge
>device (like PCI COnfig space for PCI-PCI Bridges), then I
>don't see a problem with PCI-Express error handling code
On Friday, March 18, 2005 10:26 AM Grant Grundler wrote:
>> He was referring to an unpublished draft "Error Reporting ECN".
>> You'll have to talk to Intel's PCI-SIG representative to get a copy.
>
>Good News: the "Error Reporting ECN" is now posted on the PCISIG
website.
>
>Tom, please review and
On Thursday, March 17, 2005 2:58 PM Benjamin Herrenschmidt wrote:
> Does the link side of PCIE provides a way to trigger a hard reset of
the
> rest of the card ? If not, then it's dodgy as there may be no way to
> consistently "reset" the card if it's in a bad state.
The PCI Express spec does not
On Tuesday, January 25, 2005 10:59 PM Philippe Marteau wrote:
> I saw that there is an implementation of MSI in the Linux kernel 2.6
> stream.
>
> Is there a possibility to port this in the 2.4 kernel tree (we are at
> this time using 2.4.17) ?
>
> Is this already foreseen and planned and when ?
On Thursday, March 10, 2005 9:23 PM Greg KH wrote:
>> On Thu, Mar 10, 2005 at 03:04:18PM -0800, long wrote:
>> PCI Express error signaling can occur on the PCI Express link itself
>> or on behalf of transactions initiated on the link. PCI Express
>> defines the Advanced Error Reporting capability,
On Thu Feb 24 2005 - 01:33:38 Adam Belay wrote:
>The basic flow of the new code is as follows:
>1.) A standard "driver core" driver binds to a bridge device.
>2.) When "*probe" is called it sets up the hardware and allocates a
"struct pci_bus".
>3.) The "struct pci_bus" is filled with information
25 matches
Mail list logo
