> -----Original Message----- > From: Guenter Roeck [mailto:groeck7@xxxxxxxxx] On Behalf Of Guenter > Roeck > Sent: Tuesday, December 17, 2013 7:40 PM > To: Rajat Jain > Cc: Bjorn Helgaas; Rajat Jain; Kenji Kaneshige; Alex Williamson; Yijing > Wang; linux-pci@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > Y@xxxxxxxxx > Subject: Re: [PATCH v3 4/8] pciehp: Don't disable the link permanently, > during removal > > On Wed, Dec 18, 2013 at 03:20:58AM +0000, Rajat Jain wrote: > > > > > > > -----Original Message----- > > > From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] > > > > > > [+cc yinghai@xxxxxxxxxx (seems to be Yinghai's preferred email] > > > > > > On Tue, Dec 17, 2013 at 12:06:05PM -0800, Rajat Jain wrote: > > > > We need future link up events for hot-add, thus don't disable the > > > > link permanently during device removal. Also, remove the static > > > > functions that are now left unused. > > > > > > The changelog should mention that this reverts part of 2debd9289997 > > > ("PCI: > > > pciehp: Disable/enable link during slot power off/on"). > > > > Sure, I'll add that. > > > > > > > > Yinghai, can you tell us whether this is an issue on your systems? > > > > > > > Thanks in advance Yinghai. > > > > Actually I did not understand the original problem and the solution in > > the first place (so I also do not understand how might disabling of > > presence detect notification help). If you can give more details on > > the original problem that shall be great. Here is what I understood > from the commit log: > > > > The believe the HW looks like this: > > > > PCIe port <----> Repeater <----> Device. > > > > An in addition there is the presence detect pin that is connected > > directly from The port to the device. Now, when the device is plugged > > out, the pin indicates No presence. But are you saying the PCIe link > from port to repeater is still up? > > > > Part of log: > > ==================================== > > ... > > It turns out the root complex is continually trying to train the > link to > > the repeater because the repeater has not been reset. > > > > This patch will disable the link at removal time to allow the > repeater > > to be reset properly. > > ... > > ==================================== > > > > 1) I did not understand why would port try to retrain to the link in > > either cases - Whether the link to the repeater is up or not? > > > > 2) When no link is seen, is THAT what causes repeater to go down and > > hence solve the Problem? > > > > 3) I'd expect you'd continuously get "adapter not present" messages if > > some how The driver was trying to add the device. But I did not > > understand where did "adapter present" messages came from? > > > > Sorry, but I guess I am totally confused now. I'll probably go to > > sleep :-) > > > > What, that early ? :-) I was up until 3 AM last night. "git" (or the ignorance of it) keeps me busy I guess :-) > > I think we may have a similar setup on some of our boards. Maybe we can > reproduce the situation (after we understand what exactly it is and how > to trigger it). > > Related to this patch set, I learned today that our Space product uses > mpt2sas. > Just in case we need one for testing reset functionality. > > Guenter > ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
