From: Daniel Mack <daniel@caiaq.de> To: linux-kernel@vger.kernel.org Cc: Pedro Ribeiro <pedrib@gmail.com>, akpm@linux-foundation.org, Greg KH <gregkh@suse.de>, Alan Stern <stern@rowland.harvard.edu>, alsa-devel@alsa-project.org, linux-usb@vger.kernel.org Subject: USB transfer_buffer allocations on 64bit systems Date: Wed, 7 Apr 2010 11:06:23 +0200 [thread overview] Message-ID: <20100407090623.GN30807@buzzloop.caiaq.de> (raw) Hi, I was pointed to https://bugzilla.kernel.org/show_bug.cgi?id=15580 by Pedro Ribeiro, and unfortunately I'm pretty late in the game. I wasn't aware of that thread until yesterday. While the report is quite confusing, the reason seams pretty clear to me as I've been thru quite some time-demanding debugging of a very similar issue on Mac OS X. But I'm not totally sure whether we really hit the same issue here, so I'd like to have your opinions first. The problem is appearantly the way the transfer buffer is allocated in the drivers. In the snd-usb-caiaq driver, I used kzalloc() to get memory which works fine on 32bit systems. On x86_64, however, it seems that kzalloc() hands out memory beyond the 32bit addressable boundary, which the DMA controller of the 32bit PCI-connected EHCI controller is unable to write to or read from. Am I correct on this conclusion? Depending on the condition of the memory management, things might work or not, and especially right after a reboot, there's a better chance to get lower memory. The fix is to use usb_buffer_alloc() for that purpose which ensures memory that is suitable for DMA. And on x86_64, this also means that the upper 32 bits of the address returned are all 0's. If what I've stated is true, there are quite some more drivers affected by this issue. I collected a list of places where similar fixes are needed, and I can send patches if I get a thumbs-up. Pedro is currently testing a patch I sent out yesterday. Thanks, Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Mack <daniel@caiaq.de> To: linux-kernel@vger.kernel.org Cc: alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, Greg KH <gregkh@suse.de>, Alan Stern <stern@rowland.harvard.edu>, Pedro Ribeiro <pedrib@gmail.com>, akpm@linux-foundation.org Subject: USB transfer_buffer allocations on 64bit systems Date: Wed, 7 Apr 2010 11:06:23 +0200 [thread overview] Message-ID: <20100407090623.GN30807@buzzloop.caiaq.de> (raw) Hi, I was pointed to https://bugzilla.kernel.org/show_bug.cgi?id=15580 by Pedro Ribeiro, and unfortunately I'm pretty late in the game. I wasn't aware of that thread until yesterday. While the report is quite confusing, the reason seams pretty clear to me as I've been thru quite some time-demanding debugging of a very similar issue on Mac OS X. But I'm not totally sure whether we really hit the same issue here, so I'd like to have your opinions first. The problem is appearantly the way the transfer buffer is allocated in the drivers. In the snd-usb-caiaq driver, I used kzalloc() to get memory which works fine on 32bit systems. On x86_64, however, it seems that kzalloc() hands out memory beyond the 32bit addressable boundary, which the DMA controller of the 32bit PCI-connected EHCI controller is unable to write to or read from. Am I correct on this conclusion? Depending on the condition of the memory management, things might work or not, and especially right after a reboot, there's a better chance to get lower memory. The fix is to use usb_buffer_alloc() for that purpose which ensures memory that is suitable for DMA. And on x86_64, this also means that the upper 32 bits of the address returned are all 0's. If what I've stated is true, there are quite some more drivers affected by this issue. I collected a list of places where similar fixes are needed, and I can send patches if I get a thumbs-up. Pedro is currently testing a patch I sent out yesterday. Thanks, Daniel
next reply other threads:[~2010-04-07 9:06 UTC|newest] Thread overview: 221+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-04-07 9:06 Daniel Mack [this message] 2010-04-07 9:06 ` USB transfer_buffer allocations on 64bit systems 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 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=20100407090623.GN30807@buzzloop.caiaq.de \ --to=daniel@caiaq.de \ --cc=akpm@linux-foundation.org \ --cc=alsa-devel@alsa-project.org \ --cc=gregkh@suse.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=pedrib@gmail.com \ --cc=stern@rowland.harvard.edu \ /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.