On Fri, 27 Oct 2017, Mouse wrote:
> >> But I'm not sure what sort of sync calls I need to make. [...]
> > You want to do a bus_dmamap_sync(BUS_DMASYNC_POSTREAD) [...]
> > In the NIC example above, you map the ring buffer with
> > BUS_DMA_COHERENT, fill it up and do a
> >
>>> [...access to DMA buffer while DMA in progress...ordering...]
>> Hm! On such hardware, then, you can't count on any particular
>> portion of a DMA transfer being visible until the whole transfer is
>> finished?
> Yes. I'm assuming here that the driver would do a data cache
> invalidate (for
> On Oct 27, 2017, at 10:36 AM, Mouse wrote:
>
>>> I would like to read the DMA buffer while DMA is still going on.
>>> [...] I'm fine if the CPU's view lags the hardware's view slightly,
>>> but I do care about the CPU's view of the DMA write order matching
>>> the
>> I would like to read the DMA buffer while DMA is still going on.
>> [...] I'm fine if the CPU's view lags the hardware's view slightly,
>> but I do care about the CPU's view of the DMA write order matching
>> the hardware's: that is, if the CPU sees the value written by a
>> given DMA cycle,
> On Oct 27, 2017, at 9:38 AM, Mouse wrote:
>
> ...
> I would like to read the DMA buffer while DMA is still going on. That
> is, I have a buffer of (say) 64K and the hardware is busily writing
> into it; I want to read the buffer and see what the hardware has
>
Hi Christos!
> Sent: Friday, October 27, 2017 at 1:58 PM
> From: "Christos Zoulas"
> To: tech-kern@netbsd.org
> Subject: Re: MCLGETI in if_msk.c
>
[...]
>
> OpenBSD:
> m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
> if (m == NULL)
>
Back 8 days ago, I asked about bus_dmamap_unload() at splhigh().
Thanks to very helpful off-list responses (thank you - you know who you
are!), I think I understand that a little better now. (Summary: no,
that can't be counted on to work, and it's documented, just not where I
was looking - it's
On Fri, Oct 27, 2017, 14:50 Kamil Rytarowski wrote:
> Please don't burden upstream for every single issue (for now assume
> literal meaning: "for any issue"). This worked for a while, as Dmitry
> had spare time for syzkaller for !Linux, but this time is over.
>
I asked Utkarsh to
Please don't burden upstream for every single issue (for now assume
literal meaning: "for any issue"). This worked for a while, as Dmitry
had spare time for syzkaller for !Linux, but this time is over.
You have asked others for tests, so take the responsibility now to
answer feedback reports. I'm
Adding Dmitry Vyukov to CC. He might be able to address your queries better.
Regards,
Utkarsh Anand
On 27/10/2017, Chavdar Ivanov wrote:
> I ran them twice; on both occasions somewhere around the fifth hour of work
> the laptop became unresponsive; it didn't crash, I could
I ran them twice; on both occasions somewhere around the fifth hour of work
the laptop became unresponsive; it didn't crash, I could switch the wscons,
but nothing else, so I had to reset it. The laptop didn't seem particularly
hot at the time.
It is an old T61p with 4GB memory, running 8.99.5 at
11 matches
Mail list logo