Dell Vostro 3550: pci_hotplug+acpiphp require 'pcie_aspm=force' on kernel command-line for hotplug to work

Bjorn Helgaas wrote:
> On Thu, Mar 7, 2013 at 6:47 PM, Martin Mokrejs
> <mmokrejs@fold.natur.cuni.cz> wrote:
>> Bjorn Helgaas wrote:
>>> On Wed, Mar 6, 2013 at 3:30 AM, Martin Mokrejs
>>> <mmokrejs@fold.natur.cuni.cz> wrote:
>>>> Bjorn Helgaas wrote:
>>>>> On Wed, Jan 9, 2013 at 4:10 PM, Martin Mokrejs
>>>>> <mmokrejs@fold.natur.cuni.cz> wrote:
>>>>>>   I am following up on a former thread
>>>>>> Re: 3.2.11: PCI Express card cannot be re-detected withing cca 60sec timeframe
>>>>>> about the same issue. I think I found some new info while playing with 3.7.1 kernel.
>>>>>> It happened to me that my hotplug of express cards stopped working so it made me to
>>>>>> to dive in a figure out what driver did I do to my .config, and what combinations
>>>>>> of drivers and kernel command-line parameters work and which not. This email will
>>>>>> cover just one case.
>>>>>>
>>>>>> On this Dell Vostro 3550 express card slot works if kernel is without pciehp
>>>>>> altogether and pci_hotplug+acpiphp are loaded as modules later on. The problem
>>>>>> is that I must use pcie_aspm=off.
>>>>>
>>>>> I confess I am completely bewildered here.  Something is clearly badly
>>>>> broken, but I'm having a hard time figuring out exactly what it is.  I
>>>>> think I'm overwhelmed by all the data :)
>>
>> It won't be easier now but you asked for it. ;)
> 
> Well, I didn't really ask for 500kB of logs with 150-character
> pathnames.  I am unable to process that much stuff.  I'm not
> interested in random lspci differences, virtual console bugs, or OHCI
> driver crashes at this point, so let's not muddy the waters with them.
>  I only want to figure out if pciehp can correctly detect and
> enumerate a newly inserted card, and if it can correctly clean up when
> a card is removed.  After we figure that out, we can worry about more
> complicated issues.
> 
> I *think* the bottom line of the Slot Status experiment is that the
> Presence Detect bit was reported correctly in every case, for every

I suspect you mean the shell "setpci" experiment. Please try:

s=`find . -name slot_status* | while read f; do echo -n "$f "; done`; \
 ls -latr $s | awk '{print $9}' | while read ss; do echo $ss; cat $ss; \
 done | less

and tell me why sometimes I saw 0000 -> 0140 during insert but sometimes
0100 ->  0140. For eject I always saw 0140 -> 0100. That means when repeatedly
inserting and removing a card, on the very first insert pciehp starts with 0000
and after first eject of the card it enters into the 0100 state and since that
it should always flips between expected values: 0100->0140->0100->0140 and so
on. I think am I still not correct here because I observed in the past that 
only on every second insert "kernel" recognized the card. I bet something
else comes into play otherwise I should have realized that only very first
card removal is unnoticed, not every odd removal.
However, the collected data confirms 0000->0140->0100->0140->0100->0140:

Please see ./without_USB_no_ACPIPHP_with_PCIEHP_without_microphone_USB_wakeup_USB_emulation_USB_powershare/USB3_eSATA_FireWire/slot_status_inserting_and_removing_USB3_eSATA_FireWire.txt

Although you don't seem to like the long dirnames/filenames the find command
output should make you immediately aware what was collected under what 
BIOS and kernel settings.

> card, regardless of BIOS settings.  Right?

No. The SltSta Status: and Changed: lines do not agree with each other whether
MediaCardReader is enabled or disabled in BIOS.

# without_XHCI_with_EHCI_no_ACPIPHP_with_PCIEHP/disabled_MediaCard_reader/USB3
# diff -u -w lspci_vv_initial.txt lspci_vv_inserting_USB3_card_attempt_2.txt

> 
>> The eSATA behaves differently maybe because 0100 does not change to 0140 like USB3 card but to 0103?
>> Um, the shell while loop calling setpci does not report 0103 but the driver say this:
>>
>> [  211.879397] sata_sil24 0000:11:00.0: enabling device (0100 -> 0103)
> 
> This is completely unrelated.  The shell "setpci" command is printing
> the Slot Status register; the "0100 -> 0103" above is a change in the
> PCI Command register.

OK, I mixed up two different things, sorry.

> 
>> I do not remember with 3.2.x and 3.7x kernels seeing this with the USB3 card:
>> +[  594.622211] pci 0000:11:00.0: calling quirk_usb_early_handoff+0x0/0x657
>> +[  594.622223] pci 0000:11:00.0: device not available (can't reserve [mem 0x00000000-0x00001fff 64bit])
>> +[  594.622225] pci 0000:11:00.0: Can't enable PCI device, BIOS handoff failed.
> 
> This is a result of trying to run the quirk on a hot-inserted device
> where we haven't assigned resources to it yet.  I don't think we
> should really be running quirks on a device that early.  We can look
> at that later, if we think this is related to the immediate problem.

Unless you make me to boot again into 3.9-rc1 I will believe the USB3 card
won't work under that kernel with pciehp at all, or at least while xhci is
disabled in kernel as was your requirement. The message looks scary to me
but I don't care now either. ;)

I think you really should poke through the files and check their diffs, at
least briefly. They have timestamps and the meaning of filenames should be
clear after you realize there are for each state of the computer three files:
dmesg, lspci, slot_status. From their contents you can always learn whether
card was in the slot or not.

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

Dell Vostro 3550: pci_hotplug+acpiphp require 'pcie_aspm=force' on kernel command-line for hotplug to work

Commit Message

Comments

Patch