Re: USB problems after memory upgrade

[David Brownlee <abs%netbsd.org@localhost>]

On 11 September 2011 18:16, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> 
wrote:
>> >> How hard would it be to provide a kernel option to specifically
>> >> allocate the highest possibly memory locations for devices, to try to
>> >> flush out such issues?
>> >
>> > bus_dmatag_subregion(9) is an API to handle such issue,
>> > as it was introduced for bce(4) that could not xfer to >1GB RAM.
>>
>> As I understand it, its possible that there may be similar >2GB, >4GB
>> etc issues lurking in other drivers, which would only trigger if they
>> happen to be allocated memory over such a boundary.
>>
>> I was wondering how hard it would be to have a kernel option which
>> would force all memory to be allocated from as high an address as
>> possible, to try to deterministically trigger such issues, so they
>> could be more easily found and corrected.
>
> I'm not sure if I understand your point correctly, but such restriction
> is caused by DMA hardware implementation on bus or each device.
> I don't think we can handle it by a kernel option.
>
> All memory for DMA xfers must be handled by bus_dmamem_alloc(9)
> and bus_dmamap_load(9) so that actuall DMA xfers are done against
> safe address range specified in bus_dmatag passed from a parent bus
> or specified by bus_dmatag_subregion(9) per device basis.
>
> All necessary xfers between DMA buffer and actuall target xfer regions
> are handled by bus_dmamap_sync(9), as done on ISA bounce buffer ops.

Apologies - I may have been unclear in my original response - I have a
tendency to use idioms more than necessary. I'll have one more attempt
:)

Some devices, busses, and potentially device+bus combinations have
limitations on the  memory range they can use for DMA. Where known
these are handled in the tree by enforce allocation within an
acceptable range or bounce-buffering where needed.

What I was proposing was akin to a test case - a kernel option which
would not be expected to be used in normal use, but would provide
memory to devices from the maximum permissible range.

For example, on an 8GB machine, and device which did not specify
specific memory requirements woiuld always be provided with memory
close to 8GB. If a device specified memory <4GB it would be given
memory close to 4GB. The intention is to find any device memory range
issues and to trigger them as hard and as often as possible, so they
can be discovered and fixed.

It might even be nice to have this as a (defaulted off) boot option,
similar to -1 and -2 on i386/amd64 so users can easily run the option
to help test.