Re: git: cafc839393db - main - ciss: Ignore data over/under run on RECEIVE_DIAGNOSTIC

On Thu, Oct 17, 2024 at 1:16 PM Konstantin Belousov <kostikbel@gmail.com>
wrote:

> On Mon, Oct 14, 2024 at 05:40:51AM +0000, Warner Losh wrote:
> > The branch main has been updated by imp:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=cafc839393db5c5d8000fd086118b3c7b47e95c2
> >
> > commit cafc839393db5c5d8000fd086118b3c7b47e95c2
> > Author:     Peter Eriksson <pen@lysator.liu.se>
> > AuthorDate: 2024-10-14 04:01:33 +0000
> > Commit:     Warner Losh <imp@FreeBSD.org>
> > CommitDate: 2024-10-14 05:22:19 +0000
> >
> >     ciss: Ignore data over/under run on RECEIVE_DIAGNOSTIC
> >
> >     This appears to be harmless, so ignore data over/under run on
> >     diagnostics.
> >
> >     PR: 246279
> >     Reviewed by: imp
> >     Tested by: Marek Zarychta
> >     Differential Revision: https://reviews.freebsd.org/D25155
> I am not sure what does the data overrun or underrun means in this
> context.  But ciss(4) is very unhappy with an IOMMU turned on.  It
> is so broken with it handling of DMA that controller even does not
> attach, causing faults and timing out.
>

That's a different problem. The under/overrun is technically correct,
but expected due to flaws in the firmware (I think) for certain transfers
when you don't know the size a-priori. So all the data the driver
needs comes across, but the firmware knows it has more that it
dropped on the floor so reports this status (I believe, again, don't
have the hardware or the docs and puzzled this out reading the code
doing the code review years ago, and haven't refreshed my memory
since then).


> I did not tried to read the ciss code to see where the faults come
> from.
>

Yea, I don't have the hardware, so can't help there. This was in
my backlog for people that do and have reported these patches
work for them, but the age of the original ciss adapters suggest that
it predates IOMMU deployment, so mistakes in that area would not
surprise me.

Warner