From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756927Ab0DIUPb (ORCPT ); Fri, 9 Apr 2010 16:15:31 -0400 Received: from buzzloop.caiaq.de ([212.112.241.133]:51937 "EHLO buzzloop.caiaq.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756403Ab0DIUP2 (ORCPT ); Fri, 9 Apr 2010 16:15:28 -0400 Date: Fri, 9 Apr 2010 22:14:48 +0200 From: Daniel Mack To: Alan Stern Cc: Pedro Ribeiro , Robert Hancock , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, Greg KH , alsa-devel@alsa-project.org, linux-usb@vger.kernel.org Subject: Re: USB transfer_buffer allocations on 64bit systems Message-ID: <20100409201448.GL30801@buzzloop.caiaq.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 09, 2010 at 03:34:06PM -0400, Alan Stern wrote: > On Fri, 9 Apr 2010, Pedro Ribeiro wrote: > > > > The DMA pointers do indeed look sane. I wanted to take a deeper look at > > > this and set up a 64bit system today. However, I fail to see the problem > > > here. Pedro, how much RAM does your machine have installed? > > > It has 4 GB. > > That means DMA mapping cannot be the cause of the problem. :-( FWIW, as I stated in the first message of this thread, I had very similar bug reports for a Mac OS X driver I'm maintaining, and the solution that fixed everything was to force memory that has a _physical_ buffer address mask of 0x00000000ffffffff. And all machines I've seen the bug on had 4GB of RAM or less. So appearantly, without that force option, memory beyond the 4GB range was provided. But I can't tell whether this effect also counts for Linux, and I must admit I lack a deep enough understanding about the kernel's memory management in 64bit mode and about how the DMA bouncing and remapping logic works. Does anyone have an idea about how to explain that? Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Mack Subject: Re: USB transfer_buffer allocations on 64bit systems Date: Fri, 9 Apr 2010 22:14:48 +0200 Message-ID: <20100409201448.GL30801@buzzloop.caiaq.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from buzzloop.caiaq.de (buzzloop.caiaq.de [212.112.241.133]) by alsa0.perex.cz (Postfix) with ESMTP id 5343724388 for ; Fri, 9 Apr 2010 22:15:27 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Alan Stern Cc: alsa-devel@alsa-project.org, linux-usb@vger.kernel.org, Greg KH , linux-kernel@vger.kernel.org, Pedro Ribeiro , akpm@linux-foundation.org, Robert Hancock List-Id: alsa-devel@alsa-project.org On Fri, Apr 09, 2010 at 03:34:06PM -0400, Alan Stern wrote: > On Fri, 9 Apr 2010, Pedro Ribeiro wrote: > > > > The DMA pointers do indeed look sane. I wanted to take a deeper look at > > > this and set up a 64bit system today. However, I fail to see the problem > > > here. Pedro, how much RAM does your machine have installed? > > > It has 4 GB. > > That means DMA mapping cannot be the cause of the problem. :-( FWIW, as I stated in the first message of this thread, I had very similar bug reports for a Mac OS X driver I'm maintaining, and the solution that fixed everything was to force memory that has a _physical_ buffer address mask of 0x00000000ffffffff. And all machines I've seen the bug on had 4GB of RAM or less. So appearantly, without that force option, memory beyond the 4GB range was provided. But I can't tell whether this effect also counts for Linux, and I must admit I lack a deep enough understanding about the kernel's memory management in 64bit mode and about how the DMA bouncing and remapping logic works. Does anyone have an idea about how to explain that? Daniel