lkml.org 
[lkml]   [2008]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/2] fastboot: Add a module parameter to skip probing of specific ports
On Mon, 11 Aug 2008 15:36:41 -0700
Arjan van de Ven <arjan@infradead.org> wrote:

>
> From: Kristen Accardi <kristen.c.accardi@intel.com>
> Subject: [PATCH] libata: Add a module parameter to skip probing of specific ports
>
> Port probing by libata can easily take 10% or more of the kernel boot
> time (2%+ of total). For cases where one knows there is nothing
> connected to certain ports (for example on netbooks) this is a waste
> of boot time.
>
> This patch adds a module parameter that allows the admin to specify
> to skip ports (specified by a bitmask) and recoup this boot time.
> This capability is potentially also useful to get systems to boot
> for cases where port-probing on a certain ports causes crashes.
>
> A follow-on patch will add the capability to use DMI identification
> to automate this for certain known systems.

What happens if I plug in an additional libata using device ? What
defines the probe order here particularly as people are pushing for
parallel probing of multiple devices.

This doesn't appear to make any rational sense as the mask isn't tied to
the actual bus device identifier to keep it on the same port. It might
kidn of work for an EEEPC (until you see what people retrofit into the
corners of them) but it isn't a valid general solution.

Also the EEE problem seems to be a controller specific screwup - they
didn't apparently manage the enablebits on the ATA controller correctly,
so it belongs in that driver. That also lets you tie it to the right
system, pci id, bus id so it'll always hit the right device.

(Plus double check the enables code in case you are papering over the
real bug)

Second problem is you've changed the API. Several drivers do things on
the port 0 register they know they will receive and will simply crash and
burn if you change this.

NAK this patch for now: right theory, wrong implementation. Please post a
version which uses DMI in the relevant driver and checks the PCI DEVFN
matches.



\
 
 \ /
  Last update: 2008-08-12 09:59    [W:0.094 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site