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

[Richard Lowe]

Sounded to me like Dan wanted more time.  So I'm giving it to him (I'm
not sure where we'd find rootnex experience, off the top of my head
though)

-- Rich



On Sat, May 7, 2011 at 02:23, Garrett D'Amore <garrett at nexenta.com> wrote:
> 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.
>>
>>
>
>
>
> _______________________________________________
> Advocates mailing list
> Advocates at lists.illumos.org
> http://lists.illumos.org/m/listinfo/advocates
>