[illumos-Advocates] RTI https://www.illumos.org/issues/696

[Garrett D'Amore]

Forgot to send the list of reviewers:

Reviewed by: Dan McDonald <danmcd at nexenta.com>
Reviewed by: Gordon Ross <gwr at nexenta.com>
Reviewed by: Richard Lowe <richlowe at richlowe.net>
Reviewed by: Albert Lee <trisk at nexenta.com>

Thanks.

	- Garrett

On Fri, 2011-05-06 at 23:16 -0700, Garrett D'Amore wrote:
> webrev here: http://mexico.purplecow.org/gdamore/webrev/sgllen/
> 
> garrett at thinkpad{25}> hg outgoing -v
> running ssh anonhg at hg.illumos.org "hg -R illumos-gate serve --stdio"
> remote: Not trusting file /export/illumos/hgrepos/illumos-gate/.hg/hgrc
> from untrusted user hg, group hg
> comparing with ssh://anonhg@hg.illumos.org/illumos-gate
> searching for changes
> 
> changeset:   13364:3a98c348a826
> tag:         tip
> user:        Garrett D'Amore <garrett at nexenta.com>
> date:        Fri May 06 21:42:56 2011 -0700
> 
> description:
> 	696 Incorrect check dma_attr_sgllen <= 0 in rootnex_valid_alloc_parms
> 
> modified:
>    usr/src/uts/i86pc/io/rootnex.c
> 
> 
> hg pbchk: 
> garrett at thinkpad{26}> hg pbchk
> remote: Not trusting file /export/illumos/hgrepos/illumos-gate/.hg/hgrc
> from untrusted user hg, group hg
> remote: Not trusting file /export/illumos/hgrepos/illumos-gate/.hg/hgrc
> from untrusted user hg, group hg
> Copyright check:
> 
> C style check:
> 
> Header format check:
> 
> Java style check:
> 
> Mapfile comment check:
> 
> File permission check:
> 
> Keywords check:
> 
> Comments check:
> 
> Checking for new tags:
> 
> Checking for multiple heads (or branches):
> 
> Checking for branch changes:
> 
> Checking for uncommitted changes:
> 
> Checking for merges:
> 
> No full nightly, but an incremental came back clean (log attached, note
> the proto warnings were from closed bits because I naively used cp -r
> instead of untarring the closed tarball).  I've also supplemented that
> with dmake lint in usr/src/uts (after bldenv -d) to make sure that I
> didn't introduce any lint errors.  It came back clean.
> 
> Testing:  To test this, I loaded these bits on a debug system (Thinkpad
> W510), using the debug kernel, verified that the debug checks were
> present, then also tested with a modified e1000g with the following
> change (which I'm *not* committing, this was just for test):
> 
> diff -r ef9e6008c21c usr/src/uts/common/io/e1000g/e1000g_alloc.c
> --- a/usr/src/uts/common/io/e1000g/e1000g_alloc.c       Fri May 06
> 10:04:21 2011 -0700
> +++ b/usr/src/uts/common/io/e1000g/e1000g_alloc.c       Fri May 06
> 23:12:17 2011 -0700
> @@ -107,7 +107,7 @@
>         1,                      /* minimum transfer */
>         0xffffffffU,            /* maximum transfer */
>         0xffffffffffffffffULL,  /* maximum segment length */
> -       MAX_COOKIES,            /* maximum number of segments */
> +       -1,                     /* maximum number of segments */
>         1,                      /* granularity */
>         DDI_DMA_FLAGERR,        /* dma_attr_flags */
>  };
> 
> The code seems to work well, and no issues have been noticed.
> 
>