Re: [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ +linux-pci and Yinghai as they suffered already those many emails on individual
 threads so one overviewing email hopefully won't harm] ;-)

Martin Mokrejs wrote:
> 
> 
> Bjorn Helgaas wrote:
>> On Tue, Apr 2, 2013 at 9:02 AM, Martin Mokrejs
>> <mmokrejs@xxxxxxxxxxxxxxxxxx> wrote:
>>> Hi Ying,
>>>
>>> huang ying wrote:
>>
>>>> And please give me the full dmesg for boot and incremental dmesg for
>>>> operations.
>>>
>>>
>>> The incremental bits here, the full dmesg will send only directly to your email, due to its size.
>>
>> Is there a bugzilla for this issue?  Please attach the complete dmesg
>> there or somewhere similar so we can all benefit.
> 
> I changed my mind. I am attaching the dmesg here but omitting linux-acpi
> list. After I hear a proposal from Rafel/Bjorn I will open separate bugs.
> I thought that the threads I started so far were enough but yes, dmesg
> files don't pass through list filters so I should move that to bugzilla.
> 
> so far my view of the the bugs was:
> 
> 1) acpiphp hotplug broken due to upstream pcieport 1c.7 PME# enabled
>   (eSATA-based card)

Fixed by Ying Huang port_dbg.patch applied over 3.8.5 (fixes acpiphp hotplug
of eSATA and Firewire cards, NOT the hotplug of a NEC-based USB3 card -> hence
the bug 4) below). Now I can continue using laptop-mode-tools.


> 2) xHCI dead due to to its suspend - 3.8 series and above

Not fixed by port_dbg.patch applied over 3.8.5. Interestingly, a NEC-based
XHCI card *in an express card slot* does not suffer this suspend issue.
Although it is being put into suspend if a device is unplugged.


> 3) pciehp completely broken since about 3.6, still 3.9-rc5

Even 3.9-rc5 with patch 2368081 and port_dbg.patch from Ying Huang this is
still broken (the eject of a cold plugged device from an express card slot).
That results in /proc/interrupts claiming IRQ19 is still used by the driver.
Non-forced but manual 'rmmod sata_sil24' removes the IRQ 19 from the listing.
The rmmod also removes association with sata_sil24 from the /proc/iomem but
the device 11:00 is retained in the file with its memory ranges.
lspci provides, as many times described by me, conflicting information.
Actually, I trust more lspci than /proc/ files.


> 
> 
> 
> There is one more which actually brought me into all of this in May2012 at about
> 3.2.x kernels:
> 
> 4) Even when upstream port 1c.7 is force control to 'on' hot removal of
>    USB3 express card is broken, only every second eject is recognized.
>    Is likely related to xhci_hcd having a special privilege to handle IRQ/PM
>    in its own way. In contrast, Firewire and eSATA cards work under same
>    circumstances. I see different sleep states listed as supported by those
>    cards but my bet is that is due to the exceptional xhci_hcd privilege.
>    I briefly repeated that already with 3.9-rc5.

Still broken even with port_dbg.patch applied over 3.8.5. Turns out the unnoticed
ejects and inserts are actually detected, but later, with 30sec delay of so.
Hmm, in my original thread back in 2012 I said 60sec delay but seems is likely
still the same problem:
3.2.11: PCI Express card cannot be re-detected withing cca 60sec timeframe




Before I forget, I will sketch several more bugs I hit and are all documented
in my postings from last week or two. I can provide the URLs to those postings
already in archives and maybe summarize them in bugzilla, after we agree what
will be worked on and where (email ... bugzilla), under the best matching suibject
you will propose.


5) lspci causes wake and suspend of pcieport handled devices. I fear this is
not good. Maybe it does the same to other pci devices but the "problem" is
that no other pci drivers report same type of message. I would like to see
the PME# enabled/disabled generated by other drivers as well, ideally by some
upstream, common driver.


6) sata_sil24 sometimes initializes badly under pciehp. Provided you once fix
the pciehp and still would like to get the init of sata_sil24 fixed as well.
The are two wrong paths in the driver. One is:

[  899.894862] sata_sil24 0000:11:00.0: version 1.1
[  899.894880] sata_sil24 0000:11:00.0: enabling device (0000 -> 0003)
[  899.985994] sata_sil24 0000:11:00.0: failed to clear port RST
[  900.086097] sata_sil24 0000:11:00.0: failed to clear port RST
[  900.086119] sata_sil24 0000:11:00.0: enabling bus mastering

while the other is:

[  974.021661] pcieport 0000:00:1c.0: PME# disabled
[  974.041697] pcieport 0000:00:1c.7: PME# disabled
[ 1048.450168] sata_sil24 0000:11:00.0: version 1.1
[ 1048.463692] sata_sil24 0000:11:00.0: Refused to change power state, currently in D3
[ 1048.563818] sata_sil24 0000:11:00.0: failed to clear port RST
[ 1048.663935] sata_sil24 0000:11:00.0: failed to clear port RST

Both lead to a broken device and I would prefer the driver to fail to load.
It seems they are at least in part related to early device eject while the
driver did not yet turn down an unused external SATA port.


7) It seems Rafael or Bjorn have a clue why sometimes I see only PME# disabled
or just PME# enabled in dmesg for a particular device and I am worried when was
it silently switched to the other state. I would like to hear this can be prevent
in future by some cross-checks, by design.


8) I don't know whether one can ensure that a driver releases either both
IRQ and memory ranges it has allocated, or just nothing, or an oops happens,
whatever. Maybe something could track what the driver grabbed once and make
sure both are released. even a background scan or /proc files would be fine.
The disagreement with lspci is not good.


9) In the thread 
Re: 3.8.2: stale pci device info for a previously inserted express card
I already showed an example that chimeric entries in 'lspci -vvv' output
can appear. Some data describe the previously loaded card in an Express
Card Slot while the other the one currently loaded in the slot.
This might lead to an explanation why are there those lines in lspci like:

a)
Latency: 0
Latency: 0, Cache Line Size: 64 bytes
or the Latency: line missing altogether

b)
[virtual] Expansion ROM at f6c00000 [disabled] [size=512K]
Expansion ROM at f6c00000 [size=512K]

c)
Region 0: Memory at f6c84000 (64-bit, non-prefetchable) [size=128]
Region 0: Memory at f6c84000 (64-bit, non-prefetchable) [disabled] [size=128]


If kernel does not give a hint what is wrong with a device/driver then
maybe lspci do do a runtime check and give some more useful user-oriented warning.



>>
>> I think we have two problems that may be relevant to this discussion.
>>
>> 1) The _OSC "PCI Express Capability Structure control" bit.  I don't
>> think Linux pays attention to whether the BIOS has granted us control
>> over the capability, so we may do things to it that the BIOS doesn't
>> expect.
>>
>> 2) acpiphp currently uses the presence of _ADR/_EJ0/_RMV to detect
>> hotplug slots.  I don't think this is sufficient (see
>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 for details).
>> Therefore, I don't think pci_bus_has_hotplug_slots() in port_dbg.patch
>> can be accurate.  I think it returns "false" for some buses where it
>> should return "true," such as the ExpressCard slot on Chris Clayton's
>> system (see bug 54981).
> 
> But, I do not how whether and how to split the above 4 bugs into maybe more,
> better described bugs. I will repeat them likely with 3.8.5 and 3.9-rc5,
> I got quite skilled running diff all the last days and weeks. ;-)
> 
> I am waiting for some answers from you before opening bug reports.
> Please tell me how to name them and what data you want to get where.
> After I open them will try to (re)attach your patches. Ying, do you have an
> update for the port_dbg.patch per Bjorns comments about the pci_bus_has_hotplug_slots() 
> being inaccurate? I would gladly wait for an updated patch catching rather
> more scenarios than less.

Feel free to comment on the listing of deemed bugs, add more you saw in the
logs or diffs yourself (especially those downstream, secondary bugs which will
be soon masked by the hotplug issues being *fixed*). ;)
I am quite optimistic. ;))

The above listings don't contain URLs but can be all sorted out in
those respective bugzilla entries.

Thank you,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux