Message ID | 1409899047-13045-7-git-send-email-mcgrof@do-not-panic.com |
---|---|
State | Not Applicable |
Delegated to: | David Miller |
Headers | show |
05.09.2014 12:37, Luis R. Rodriguez пишет: > From: "Luis R. Rodriguez" <mcgrof@suse.com> > > Alexander reported that on his Sony VAIO VPCZ23A4R laptop > experiences long delays on boot when connected to its dock > station on pre 3.9 kernels but anything after 3.9 will cause > the device to not be detected at all ending with: > > [ 38.065673] pata_marvell 0000:1a:00.0: no available native port > [ 38.065769] pata_acpi 0000:1a:00.0: no available native port I object to this commit message, it is based on outdated information and is due to a different bug that was fixed in 3.10 as a last-minute fix. Modern kernels just experience long delays during boot. > This laptop has a Marvell 88SE6121 SATA II Controller [11ab:6121] > and a BluRay writer attached. The reason for the delays are > caused by SRST errors and the link being slow to respond. > The pata_marvell driver is a simple libata wrapper so the > real required changes need to be made on libata however not > many folks are around and available anymore with intimate > knowledge and experience with these devices. Alexander notes > that it may be that *any* ATA BMDMA controller that fails to > respond to an identify command until a reset or other device > poking might suffer from similar fate, this needs to be > investigated further. Using async probe the issue caused > by systemd killing the driver after taking over 30 seconds > on probe. > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=59581 > > Cc: Tejun Heo <tj@kernel.org> > Cc: linux-ide@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> > Cc: Oleg Nesterov <oleg@redhat.com> > Cc: Benjamin Poirier <bpoirier@suse.de> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: patrakov@gmail.com > Reported-by: "Alexander E. Patrakov" <patrakov@gmail.com> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> > --- > drivers/ata/pata_marvell.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c > index ae9feb1..6a543b9 100644 > --- a/drivers/ata/pata_marvell.c > +++ b/drivers/ata/pata_marvell.c > @@ -175,6 +175,7 @@ static struct pci_driver marvell_pci_driver = { > .suspend = ata_pci_device_suspend, > .resume = ata_pci_device_resume, > #endif > + .driver.async_probe = true, > }; > > module_pci_driver(marvell_pci_driver); >
On Thu, Sep 04, 2014 at 11:37:27PM -0700, Luis R. Rodriguez wrote: > diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c > index ae9feb1..6a543b9 100644 > --- a/drivers/ata/pata_marvell.c > +++ b/drivers/ata/pata_marvell.c > @@ -175,6 +175,7 @@ static struct pci_driver marvell_pci_driver = { > .suspend = ata_pci_device_suspend, > .resume = ata_pci_device_resume, > #endif > + .driver.async_probe = true, You can't do this. There's nothing special about pata_marvell. Sure there was a bug report which made long probe durations more common on this driver on certain configurations but those long durations can happen on *any* libata driver and singling out pata_marvell for async probing is adding a different probing behavior basically arbitrarily. I really can't see how this marking random drivers with async probing would work, so one driver does synchronous probing while the equivalent next one doesn't? That's crazy. Thanks.
diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c index ae9feb1..6a543b9 100644 --- a/drivers/ata/pata_marvell.c +++ b/drivers/ata/pata_marvell.c @@ -175,6 +175,7 @@ static struct pci_driver marvell_pci_driver = { .suspend = ata_pci_device_suspend, .resume = ata_pci_device_resume, #endif + .driver.async_probe = true, }; module_pci_driver(marvell_pci_driver);