lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Dec 2013 04:06:07 +0000
From:	Rajat Jain <rajatjain@...iper.net>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Rajat Jain <rajatjain.linux@...il.com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	Yijing Wang <wangyijing@...wei.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Y@...per.es" <Y@...per.es>
Subject: RE: [PATCH v3 4/8] pciehp: Don't disable the link permanently,
 during removal



> -----Original Message-----
> From: Guenter Roeck [mailto:groeck7@...il.com] 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@...r.kernel.org; linux-kernel@...r.kernel.org;
> Y@...per.es
> 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@...gle.com]
> > >
> > > [+cc yinghai@...nel.org (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
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ