On 15 May 2021, at 21:56, Mateusz Guzik <mjgu...@gmail.com> wrote:
> 
> One of these commits breaks tinderbox:
> i386 MINIMAL kernel failed, check _.i386.MINIMAL for details
> i386 GENERIC kernel failed, check _.i386.GENERIC for details
> i386 GENERIC-NODEBUG kernel failed, check _.i386.GENERIC-NODEBUG for details
> i386 PAE kernel failed, check _.i386.PAE for details
> i386 LINT kernel failed, check _.i386.LINT for details
> i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details
> i386 LINT-NOINET6 kernel failed, check _.i386.LINT-NOINET6 for details
> i386 LINT-NOIP kernel failed, check _.i386.LINT-NOIP for details
> 
> /usr/src/sys/dev/cxgbe/tom/t4_ddp.c:1045:15: error: invalid operands
> to binary expression ('void *' and 'int')
>                start_pva = trunc_page(sgl->addr);
>                            ^~~~~~~~~~~~~~~~~~~~~
> ./machine/param.h:150:29: note: expanded from macro 'trunc_page'
> #define trunc_page(x)           ((x) & ~PAGE_MASK)
>                                 ~~~ ^ ~~~~~~~~~~
> /usr/src/sys/dev/cxgbe/tom/t4_ddp.c:1300:8: error: invalid operands to
> binary expression ('void *' and 'int')
>        pva = trunc_page(sgl->addr);
>              ^~~~~~~~~~~~~~~~~~~~~
> ./machine/param.h:150:29: note: expanded from macro 'trunc_page'
> #define trunc_page(x)           ((x) & ~PAGE_MASK)
>                                 ~~~ ^ ~~~~~~~~~~

It seems amd64, arm64 and riscv cast to unsigned long first, but arm, i386,
mips and powerpc do not. These macros should probably just become MI in
sys/sys/param.h rather than fixing the MD copies to include casts.

Jess

> On 5/14/21, John Baldwin <j...@freebsd.org> wrote:
>> The branch main has been updated by jhb:
>> 
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=e73e2ee0acf5a0e0f47b9c2bcd73c835c4922fab
>> 
>> commit e73e2ee0acf5a0e0f47b9c2bcd73c835c4922fab
>> Author:     John Baldwin <j...@freebsd.org>
>> AuthorDate: 2021-05-14 19:20:57 +0000
>> Commit:     John Baldwin <j...@freebsd.org>
>> CommitDate: 2021-05-14 19:21:34 +0000
>> 
>>    cxgbei: Handle target transfers with excess unsolicited data.
>> 
>>    The CTL frontend might have provided a buffer that is smaller than the
>>    FirstBurstLength and thus smaller than the amount of unsolicited data
>>    included in the request PDU.  Treat these transfers as an empty
>>    transfer.
>> 
>>    Reported by:    Jithesh Arakkan @ Chelsio
>>    Sponsored by:   Chelsio Communications
>> 
>>    Differential Revision:  https://reviews.freebsd.org/D29940
>> ---
>> sys/dev/cxgbe/cxgbei/icl_cxgbei.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>> 
>> diff --git a/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> b/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> index 7f638c96483a..c4eb4a35ad31 100644
>> --- a/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> +++ b/sys/dev/cxgbe/cxgbei/icl_cxgbei.c
>> @@ -1064,10 +1064,15 @@ icl_cxgbei_conn_transfer_setup(struct icl_conn *ic,
>> union ctl_io *io,
>>              /*
>>               * Note that ICL calls conn_transfer_setup even if the first
>>               * burst had everything and there's nothing left to transfer.
>> +             *
>> +             * NB: The CTL frontend might have provided a buffer
>> +             * whose length (kern_data_len) is smaller than the
>> +             * FirstBurstLength of unsolicited data.  Treat those
>> +             * as an empty transfer.
>>               */
>> -            MPASS(ctsio->kern_data_len >= first_burst);
>>              xferlen = ctsio->kern_data_len;
>> -            if (xferlen - first_burst < ci->ddp_threshold) {
>> +            if (xferlen < first_burst ||
>> +                xferlen - first_burst < ci->ddp_threshold) {
>> no_ddp:
>>                      /*
>>                       * No DDP for this transfer.  Allocate a TTT (based on
>> 
> 
> 
> -- 
> Mateusz Guzik <mjguzik gmail.com>
_______________________________________________
dev-commits-src-main@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"

Reply via email to