Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751217AbWEIWIn (ORCPT ); Tue, 9 May 2006 18:08:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751205AbWEIWIn (ORCPT ); Tue, 9 May 2006 18:08:43 -0400 Received: from mga03.intel.com ([143.182.124.21]:38550 "EHLO azsmga101-1.ch.intel.com") by vger.kernel.org with ESMTP id S1751191AbWEIWIm convert rfc822-to-8bit (ORCPT ); Tue, 9 May 2006 18:08:42 -0400 X-IronPort-AV: i="4.05,107,1146466800"; d="scan'208"; a="33946476:sNHT650684475" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: RE: [PATCH 2/3] swiotlb: create __alloc_bootmem_low_nopanic and add support in SWIOTLB Date: Tue, 9 May 2006 15:08:36 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 2/3] swiotlb: create __alloc_bootmem_low_nopanic and add support in SWIOTLB Thread-Index: AcZzr1jK8NykJpdnQWiy3lVoOpLO+QAAhBMA From: "Luck, Tony" To: "Jon Mason" Cc: "Muli Ben-Yehuda" , , , , X-OriginalArrivalTime: 09 May 2006 22:08:36.0954 (UTC) FILETIME=[1ECB1BA0:01C673B5] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1513 Lines: 29 > Ah, then I better describe it. The patch makes it possible to recover > from an insufficient amount of bootmem during swiotlb_init (instead of > panicing). For x86_64, I have it bailing out (via the returned int from > swiotlb_init and using the non-iommu DMA routines from > arch/x86_64/kernel/pci-nommu.c). For ia64, its not that simple. > There are no alternative DMA routines to switch to incase of an error. > Also, There is no way to "bail-out" from its mem_init. I could add a > panic there, if that is more palatable. Presumably if you have insufficient memory to allocate the swiotlb buffers, then you actually don't need *any* swiotlb buffers at all as all your memory is at low enough addresses to be directly accessed by whatever devices you have (offer void on bizarre discontig systems that put the only memory they have in an address range that can't be used by the devices that need to access it ... but perhaps in that case it would be better to buy a different computer :-) But ignoring that ... a new "noop" routine that returns an int does seem to be the right solution. Looking at the others that are already there, calling it machvec_noop_dma() isn't a bad fit with the style of the other "_noop" functions that are already there. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/