From: Alan Stern <stern@rowland.harvard.edu> To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: dwmw2@infradead.org, <daniel@caiaq.de>, <clemens@ladisch.de>, <tiwai@suse.de>, <alsa-devel@alsa-project.org>, <gregkh@suse.de>, <konrad.wilk@oracle.com>, <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <chrisw@sous-sol.org>, <iommu@lists.linux-foundation.org>, <andi@firstfloor.org>, <pedrib@gmail.com>, <akpm@linux-foundation.org> Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems Date: Tue, 11 May 2010 10:00:50 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1005110956330.1834-100000@iolanthe.rowland.org> (raw) In-Reply-To: <20100511100637D.fujita.tomonori@lab.ntt.co.jp> On Tue, 11 May 2010, FUJITA Tomonori wrote: > > > > > At one point we tried an experiment, printing out the buffer and DMA > > > > > addresses. I don't recall seeing anything obviously wrong, but if an > > > > > IOMMU was in use then that might not mean anything. Is it possible > > > > > that the IOMMU mappings sometimes get messed up for addresses above 4 > > > > > GB? > > > > > > > > You mean that an IOMMU could allocate an address above 4GB wrongly? If > > > > so, IIRC, all the IOMMU implementations use dev->dma_mask and > > > > dev->coherent_dma_mask properly. And the DMA address space of the > > > > majority of IOMMUs are limited less than 4GB. > > > > > > The Intel IOMMU code will use dev->dma_mask and dev->coherent_dma_mask > > > properly. It is not limited to 4GiB, but it will tend to give virtual > > > DMA addresses below 4GiB even when a device is capable of more; it'll > > > only give out higher addresses when the address space below 4GiB is > > > exhausted. > > > > What I meant was: Is it possible that the IOMMU code will return a > > virtual DMA address before 4 GB but will somehow forget to actually map > > that address to the data buffer? > > Then, the IOMMU is completely broken. Then, we would get tons of DMA > bugs not only about USB, I guess. So I'm not sure. Yes, you're right about that. > > The problem goes away when Pedro boots with mem=4G. And the dma_mask > > value is set properly (in fact, the ehci-hcd driver currently doesn't > > use 64-bit DMA at all). > > > > If anyone wants to see the debug log entries showing the buffer and DMA > > addresses, they are attached to this email message: > > > > http://marc.info/?l=linux-kernel&m=127076841801054&w=2 > > > > Either the data isn't getting written to the buffer correctly or else > > the buffer isn't getting sent to the device correctly. Can anybody > > suggest a means of determining which is the case? > > I can't say anything about this log that including only DMA addresses. > I'm not familiar with how the USB core does DMA stuff. And the USB > stack design that the USB core does DMA stuff (allocating, mappings, > etc) makes debugging DMA issues really difficult. The DMA stuff is simple enough in this case. The urb->transfer_buffer address is passed to dma_map_single(), and the DMA address it returns is stored in urb->transfer_dma. Those are the two values printed out by the debugging patch. Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> To: FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org> Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, daniel-rDUAYElUppE@public.gmane.org, clemens-P6GI/4k7KOmELgA04lAiVw@public.gmane.org, tiwai-l3A5Bk7waGM@public.gmane.org, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, gregkh-l3A5Bk7waGM@public.gmane.org, konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org, pedrib-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org Subject: Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems Date: Tue, 11 May 2010 10:00:50 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1005110956330.1834-100000@iolanthe.rowland.org> (raw) In-Reply-To: <20100511100637D.fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org> On Tue, 11 May 2010, FUJITA Tomonori wrote: > > > > > At one point we tried an experiment, printing out the buffer and DMA > > > > > addresses. I don't recall seeing anything obviously wrong, but if an > > > > > IOMMU was in use then that might not mean anything. Is it possible > > > > > that the IOMMU mappings sometimes get messed up for addresses above 4 > > > > > GB? > > > > > > > > You mean that an IOMMU could allocate an address above 4GB wrongly? If > > > > so, IIRC, all the IOMMU implementations use dev->dma_mask and > > > > dev->coherent_dma_mask properly. And the DMA address space of the > > > > majority of IOMMUs are limited less than 4GB. > > > > > > The Intel IOMMU code will use dev->dma_mask and dev->coherent_dma_mask > > > properly. It is not limited to 4GiB, but it will tend to give virtual > > > DMA addresses below 4GiB even when a device is capable of more; it'll > > > only give out higher addresses when the address space below 4GiB is > > > exhausted. > > > > What I meant was: Is it possible that the IOMMU code will return a > > virtual DMA address before 4 GB but will somehow forget to actually map > > that address to the data buffer? > > Then, the IOMMU is completely broken. Then, we would get tons of DMA > bugs not only about USB, I guess. So I'm not sure. Yes, you're right about that. > > The problem goes away when Pedro boots with mem=4G. And the dma_mask > > value is set properly (in fact, the ehci-hcd driver currently doesn't > > use 64-bit DMA at all). > > > > If anyone wants to see the debug log entries showing the buffer and DMA > > addresses, they are attached to this email message: > > > > http://marc.info/?l=linux-kernel&m=127076841801054&w=2 > > > > Either the data isn't getting written to the buffer correctly or else > > the buffer isn't getting sent to the device correctly. Can anybody > > suggest a means of determining which is the case? > > I can't say anything about this log that including only DMA addresses. > I'm not familiar with how the USB core does DMA stuff. And the USB > stack design that the USB core does DMA stuff (allocating, mappings, > etc) makes debugging DMA issues really difficult. The DMA stuff is simple enough in this case. The urb->transfer_buffer address is passed to dma_map_single(), and the DMA address it returns is stored in urb->transfer_dma. Those are the two values printed out by the debugging patch. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-05-11 14:00 UTC|newest] Thread overview: 221+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-04-07 9:06 USB transfer_buffer allocations on 64bit systems Daniel Mack 2010-04-07 9:06 ` Daniel Mack [not found] ` <p2g581ef6d61004070220z1153d40ez955b356e01220848@mail.gmail.com> 2010-04-07 9:26 ` USB HID gadget driver (was: Re: USB transfer_buffer allocations on 64bit systems) Daniel Mack 2010-04-07 9:26 ` Daniel Mack 2010-04-07 14:59 ` USB transfer_buffer allocations on 64bit systems Alan Stern 2010-04-07 14:59 ` Alan Stern 2010-04-07 15:11 ` Daniel Mack 2010-04-07 15:11 ` Daniel Mack 2010-04-07 15:31 ` Greg KH 2010-04-07 15:31 ` Greg KH 2010-04-07 15:35 ` Daniel Mack 2010-04-07 15:35 ` Daniel Mack 2010-04-07 15:51 ` Greg KH 2010-04-07 15:51 ` Greg KH 2010-04-07 16:04 ` Alan Stern 2010-04-07 16:04 ` Alan Stern 2010-04-08 6:09 ` Oliver Neukum 2010-04-08 11:07 ` Daniel Mack 2010-04-08 11:07 ` Daniel Mack 2010-04-07 15:55 ` Alan Stern 2010-04-07 15:55 ` Alan Stern 2010-04-07 16:16 ` Daniel Mack 2010-04-07 16:16 ` Daniel Mack 2010-04-07 16:47 ` Alan Stern 2010-04-07 16:47 ` Alan Stern 2010-04-07 17:55 ` Takashi Iwai 2010-04-07 17:55 ` Takashi Iwai 2010-04-07 17:59 ` Daniel Mack 2010-04-07 17:59 ` Daniel Mack 2010-04-07 18:06 ` Takashi Iwai 2010-04-07 18:06 ` Takashi Iwai 2010-04-07 19:13 ` Alan Stern 2010-04-07 19:13 ` Alan Stern 2010-04-07 23:59 ` Robert Hancock 2010-04-07 23:59 ` Robert Hancock 2010-04-08 0:33 ` Greg KH 2010-04-08 0:33 ` Greg KH 2010-04-09 0:01 ` Robert Hancock 2010-04-09 16:50 ` Sarah Sharp 2010-04-09 16:50 ` Sarah Sharp 2010-04-09 23:38 ` Robert Hancock 2010-04-09 23:38 ` Robert Hancock 2010-04-10 8:34 ` [alsa-devel] " Daniel Mack 2010-04-10 8:34 ` Daniel Mack 2010-04-10 17:02 ` [alsa-devel] " Robert Hancock 2010-04-12 18:56 ` Sarah Sharp 2010-04-12 20:39 ` Robert Hancock 2010-04-12 20:39 ` Robert Hancock 2010-04-12 20:58 ` Sarah Sharp 2010-04-12 11:17 ` [PATCH] USB: rename usb_buffer_alloc() and usb_buffer_free() Daniel Mack 2010-04-12 11:17 ` Daniel Mack 2010-04-13 18:16 ` Daniel Mack 2010-04-13 18:16 ` Daniel Mack 2010-04-13 19:27 ` Alan Stern 2010-04-13 19:27 ` Alan Stern 2010-04-13 20:26 ` Greg KH 2010-04-13 21:47 ` Daniel Mack 2010-04-13 21:47 ` Daniel Mack 2010-04-07 17:52 ` USB transfer_buffer allocations on 64bit systems Takashi Iwai 2010-04-07 17:52 ` Takashi Iwai 2010-04-07 15:46 ` Alan Stern 2010-04-07 15:46 ` Alan Stern 2010-04-08 6:12 ` Oliver Neukum 2010-04-08 16:59 ` Alan Stern 2010-04-08 16:59 ` Alan Stern 2010-04-08 21:24 ` Oliver Neukum 2010-04-08 22:20 ` Alan Stern 2010-04-08 22:20 ` Alan Stern 2010-04-09 6:04 ` Oliver Neukum 2010-04-09 14:41 ` Alan Stern 2010-04-09 14:41 ` Alan Stern 2010-04-09 14:50 ` Oliver Neukum 2010-04-09 14:50 ` Oliver Neukum 2010-04-09 15:15 ` Alan Stern 2010-04-09 15:15 ` Alan Stern 2010-04-09 20:51 ` Oliver Neukum 2010-04-09 20:51 ` Oliver Neukum 2010-04-09 21:21 ` Alan Stern 2010-04-09 21:21 ` Alan Stern 2010-04-07 16:54 ` Oliver Neukum 2010-04-07 16:54 ` Oliver Neukum 2010-04-07 17:00 ` Daniel Mack 2010-04-07 17:00 ` Daniel Mack 2010-04-07 23:55 ` Robert Hancock 2010-04-07 23:55 ` Robert Hancock 2010-04-08 2:10 ` Alan Stern 2010-04-08 2:10 ` Alan Stern 2010-04-08 7:30 ` Daniel Mack 2010-04-08 7:30 ` Daniel Mack 2010-04-08 16:57 ` Alan Stern 2010-04-08 16:57 ` Alan Stern 2010-04-08 17:17 ` Pedro Ribeiro 2010-04-08 18:17 ` Alan Stern 2010-04-08 23:13 ` Pedro Ribeiro 2010-04-08 23:13 ` Pedro Ribeiro 2010-04-09 16:01 ` Alan Stern 2010-04-09 16:01 ` Alan Stern 2010-04-09 18:09 ` Daniel Mack 2010-04-09 18:19 ` Pedro Ribeiro 2010-04-09 18:19 ` Pedro Ribeiro 2010-04-09 19:34 ` Alan Stern 2010-04-09 19:34 ` Alan Stern 2010-04-09 20:14 ` Daniel Mack 2010-04-09 20:14 ` Daniel Mack 2010-04-09 20:25 ` [LKML] " Konrad Rzeszutek Wilk 2010-04-09 20:25 ` Konrad Rzeszutek Wilk 2010-04-09 21:23 ` Alan Stern 2010-04-09 21:23 ` Alan Stern 2010-04-09 22:11 ` Robert Hancock 2010-04-12 10:48 ` Daniel Mack 2010-04-12 10:48 ` Daniel Mack 2010-04-12 12:06 ` Pedro Ribeiro 2010-04-10 12:49 ` Daniel Mack 2010-04-10 12:49 ` Daniel Mack 2010-04-10 13:21 ` Pedro Ribeiro 2010-04-10 13:21 ` Pedro Ribeiro 2010-04-12 8:59 ` Andi Kleen 2010-04-12 8:59 ` Andi Kleen 2010-04-12 11:14 ` Daniel Mack 2010-04-12 11:14 ` Daniel Mack 2010-04-12 11:53 ` Andi Kleen 2010-04-12 11:53 ` Andi Kleen 2010-04-12 12:11 ` Pedro Ribeiro 2010-04-12 12:12 ` Andi Kleen 2010-04-12 12:12 ` Andi Kleen 2010-04-12 12:32 ` Daniel Mack 2010-04-12 12:47 ` Andi Kleen 2010-04-12 12:54 ` Daniel Mack 2010-04-12 12:54 ` Daniel Mack 2010-04-12 15:43 ` Andi Kleen 2010-04-12 16:17 ` Alan Stern 2010-04-12 16:17 ` Alan Stern 2010-04-12 16:29 ` Andi Kleen 2010-04-12 16:57 ` Alan Stern 2010-04-12 16:57 ` Alan Stern 2010-04-12 17:15 ` Daniel Mack 2010-04-12 17:15 ` Daniel Mack 2010-04-12 17:22 ` Andi Kleen 2010-04-12 17:22 ` Andi Kleen 2010-04-12 17:56 ` Daniel Mack 2010-04-12 17:56 ` Daniel Mack 2010-04-12 17:52 ` [LKML] " Konrad Rzeszutek Wilk 2010-04-12 17:52 ` Konrad Rzeszutek Wilk 2010-04-13 18:22 ` Daniel Mack 2010-04-13 18:22 ` Daniel Mack 2010-04-13 23:46 ` Pedro Ribeiro 2010-04-13 23:46 ` Pedro Ribeiro 2010-04-14 10:09 ` Daniel Mack 2010-04-14 10:09 ` Daniel Mack 2010-04-14 10:47 ` Pedro Ribeiro 2010-04-14 11:02 ` Pedro Ribeiro 2010-04-14 13:18 ` [LKML] " Konrad Rzeszutek Wilk 2010-04-14 14:08 ` Alan Stern 2010-04-14 14:08 ` Alan Stern 2010-04-14 16:36 ` Daniel Mack 2010-04-14 16:36 ` Daniel Mack 2010-04-14 17:21 ` Pedro Ribeiro 2010-04-14 17:21 ` Pedro Ribeiro 2010-04-14 18:23 ` Alan Stern 2010-04-14 18:27 ` Pedro Ribeiro 2010-04-14 18:53 ` Alan Stern 2010-04-15 7:35 ` Daniel Mack 2010-04-15 7:35 ` Daniel Mack 2010-04-14 18:15 ` Alan Stern 2010-04-14 18:36 ` David Woodhouse 2010-04-14 21:12 ` Pedro Ribeiro 2010-04-14 22:25 ` Chris Wright 2010-04-14 22:56 ` Pedro Ribeiro 2010-04-14 23:37 ` Chris Wright 2010-04-15 1:20 ` Pedro Ribeiro 2010-04-15 15:20 ` Alan Stern 2010-04-20 0:16 ` Pedro Ribeiro 2010-05-07 7:48 ` Daniel Mack 2010-05-07 7:48 ` Daniel Mack 2010-05-07 9:47 ` [alsa-devel] " Clemens Ladisch 2010-05-07 9:47 ` Clemens Ladisch 2010-05-07 10:24 ` [alsa-devel] " Daniel Mack 2010-05-07 10:24 ` Daniel Mack 2010-05-07 14:51 ` [alsa-devel] " Alan Stern 2010-05-07 14:51 ` Alan Stern 2010-05-10 2:50 ` FUJITA Tomonori 2010-05-10 9:21 ` David Woodhouse 2010-05-10 9:21 ` David Woodhouse 2010-05-10 14:58 ` [alsa-devel] " Alan Stern 2010-05-10 14:58 ` Alan Stern 2010-05-11 1:06 ` FUJITA Tomonori 2010-05-11 1:06 ` FUJITA Tomonori 2010-05-11 14:00 ` Alan Stern [this message] 2010-05-11 14:00 ` Alan Stern 2010-05-11 14:22 ` FUJITA Tomonori 2010-05-11 14:24 ` Konrad Rzeszutek Wilk 2010-05-11 14:38 ` FUJITA Tomonori 2010-05-11 15:04 ` Alan Stern 2010-05-11 15:04 ` Alan Stern 2010-05-11 15:34 ` FUJITA Tomonori 2010-05-11 16:06 ` Alan Stern 2010-05-11 16:09 ` Daniel Mack 2010-05-11 16:48 ` Pedro Ribeiro 2010-05-11 17:10 ` Daniel Mack 2010-05-11 17:32 ` Pedro Ribeiro 2010-05-11 17:38 ` Daniel Mack 2010-05-12 23:50 ` Pedro Ribeiro 2010-05-13 9:36 ` Daniel Mack 2010-05-14 0:17 ` Pedro Ribeiro 2010-05-11 14:57 ` Alan Stern 2010-05-11 15:05 ` Daniel Mack 2010-05-10 14:31 ` Konrad Rzeszutek Wilk 2010-05-10 14:31 ` Konrad Rzeszutek Wilk 2010-05-07 11:42 ` Oliver Neukum 2010-05-07 11:42 ` Oliver Neukum 2010-05-07 11:47 ` Oliver Neukum 2010-05-07 11:47 ` Oliver Neukum 2010-05-07 11:58 ` Daniel Mack 2010-05-07 11:58 ` Daniel Mack 2010-05-07 14:45 ` [alsa-devel] " Alan Stern 2010-05-07 14:45 ` Alan Stern 2010-04-14 18:38 ` Chris Wright 2010-04-14 20:29 ` Alan Stern 2010-04-14 21:01 ` Konrad Rzeszutek Wilk 2010-04-14 21:12 ` Pedro Ribeiro 2010-04-15 1:50 ` Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.44L0.1005110956330.1834-100000@iolanthe.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=akpm@linux-foundation.org \ --cc=alsa-devel@alsa-project.org \ --cc=andi@firstfloor.org \ --cc=chrisw@sous-sol.org \ --cc=clemens@ladisch.de \ --cc=daniel@caiaq.de \ --cc=dwmw2@infradead.org \ --cc=fujita.tomonori@lab.ntt.co.jp \ --cc=gregkh@suse.de \ --cc=iommu@lists.linux-foundation.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=pedrib@gmail.com \ --cc=tiwai@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.