Hi Ian,
Please find attached a patch which disable the double mapping of
allocated DMA capable buffers in the USB stack for all drivers.
Can you test it and check out the total memory usage before and after
the patch? Also verify it if makes any difference on any platforms.
Thank you!
On Wed, 2015-01-14 at 06:13 +0100, Hans Petter Selasky wrote:
On 01/13/15 21:25, Ian Lepore wrote:
On Tue, 2015-01-13 at 17:52 +0100, Hans Petter Selasky wrote:
On 01/13/15 17:29, Ian Lepore wrote:
On Tue, 2015-01-13 at 16:57 +0100, Hans Petter Selasky wrote:
[...]
Hi,
Can you give
On 01/14/15 16:03, Ian Lepore wrote:
If you are allocating the memory using bus_dmamem_alloc() then no,
absolutely not. It's working for you by accident because of the
USB_HOST_ALIGN hacks which I think date back to freebsd 8 or so.
When I talked to you a couple years ago about doing it the
with the USB driver using the busdma
routines incorrectly, which accidentally works okay on x86 platforms but
likely not so well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush() or
usb_pc_cpu_invalidate():
void
usb_pc_cpu_flush(struct usb_page_cache *pc)
{
if (pc
Hi Kott,
Can you tell us which ARM kernel configuration file you are using for
FreeBSD? Reading through this thread I cannot see this piece of
information yet.
Have you tested other ARM platforms?
Thank you,
--HPS
___
freebsd-usb@freebsd.org
with the USB driver using the busdma
routines incorrectly, which accidentally works okay on x86 platforms but
likely not so well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush() or
usb_pc_cpu_invalidate():
void
usb_pc_cpu_flush(struct usb_page_cache *pc)
{
if (pc
problems with l2 cache on armv7 right
now. There are known problems with the USB driver using the busdma
routines incorrectly, which accidentally works okay on x86 platforms but
likely not so well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush() or
usb_pc_cpu_invalidate
Except that there are no known problems with l2 cache on armv7 right
now. There are known problems with the USB driver using the busdma
routines incorrectly, which accidentally works okay on x86 platforms but
likely not so well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush
well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush() or
usb_pc_cpu_invalidate():
void
usb_pc_cpu_flush(struct usb_page_cache *pc)
{
if (pc-page_offset_end == pc-page_offset_buf) {
/* nothing has been loaded into this page cache
platforms but
likely not so well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush() or
usb_pc_cpu_invalidate():
void
usb_pc_cpu_flush(struct usb_page_cache *pc)
{
if (pc-page_offset_end == pc-page_offset_buf) {
/* nothing has been loaded into this page cache
On 01/13/15 17:52, Hans Petter Selasky wrote:
Hi,
Can you give an example of a NIC driver which you consider a good
example which use DMA both for data (not only mbufs) and the control
path and use busdma as you consider to be correct?
--HPS
So that I can compare this agains what USB is
the busdma
routines incorrectly, which accidentally works okay on x86 platforms but
likely not so well on others.
Hi,
If there is a problem it is in usb_pc_cpu_flush() or
usb_pc_cpu_invalidate():
void
usb_pc_cpu_flush(struct usb_page_cache *pc)
{
if (pc
Will check with cache disabled. this may be the problem
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/usb-pc-cpu-flush-tp5975583p5976832.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
___
Hi,
There might be an option somewhere you can set in the boot enviroment,
which will disable the CPU cache ... I guess something is failing in
that area. Else we would see the same with regular PCs too.
--HPS
___
freebsd-usb@freebsd.org mailing
On 12/24/14 04:41, kott via freebsd-usb wrote:
the value of r0 is 0.
Hi,
In the function _ehci_append_qh do you know if it is the second or
first call to usb_pc_cpu_flush which fails. The pointer which is
passed as an argument to this function resides in the memory which is
flushed, so
Thanks
platform is freebsd10 , armv7 based.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/usb-pc-cpu-flush-tp5975583p5975752.html
Sent from the freebsd-usb mailing list archive at Nabble.com.
___
freebsd-usb@freebsd.org
This platform is armv7 freebsd10. it does fail in the second usb_pc_cpu_flush
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/usb-pc-cpu-flush-tp5975583p5975763.html
Sent from the freebsd-usb mailing list archive at Nabble.com
did try with freebsd11 also and it fails in the same point at
usb_pc_cpu_flush.
Is this a known issue ? any suggestions would help
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/usb-pc-cpu-flush-tp5975583p5975773.html
Sent from the freebsd-usb mailing list archive
On 12/24/14 15:35, kott via freebsd-usb wrote:
did try with freebsd11 also and it fails in the same point at
usb_pc_cpu_flush.
Is this a known issue ? any suggestions would help
This is not a known issue. Which ARM kernel are you building?
--HPS
(0xc73ece74) locked @
sys/dev/usb/usb_transfer.c
exclusive sleep mutex USB device mutex (USB device mutex) r = 0 (0xc73da850)
locked @ /sys/dev/usb/usb_transfer.c
Stopped at usb_pc_cpu_flush+0xc: ldr r2, [r0, #0x018]
Thanks
kott
--
View this message
ehci0 (usb_def_mtx) r = 0 (0xc73ece74) locked @
sys/dev/usb/usb_transfer.c
exclusive sleep mutex USB device mutex (USB device mutex) r = 0 (0xc73da850)
locked @ /sys/dev/usb/usb_transfer.c
Stopped at usb_pc_cpu_flush+0xc: ldr r2, [r0, #0x018]
Thanks
kott
21 matches
Mail list logo
