Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756698AbYH0Ptg (ORCPT ); Wed, 27 Aug 2008 11:49:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753730AbYH0Pt0 (ORCPT ); Wed, 27 Aug 2008 11:49:26 -0400 Received: from mail2.shareable.org ([80.68.89.115]:35008 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753486AbYH0PtZ (ORCPT ); Wed, 27 Aug 2008 11:49:25 -0400 Date: Wed, 27 Aug 2008 16:48:05 +0100 From: Jamie Lokier To: Bernd Petrovitsch Cc: Parag Warudkar , Linus Torvalds , Adrian Bunk , Rusty Russell , "Alan D. Brunelle" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Andrew Morton , Arjan van de Ven , Ingo Molnar , linux-embedded@vger.kernel.org Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected Message-ID: <20080827154805.GA25387@shareable.org> References: <20080826183051.GB10925@cs181140183.pp.htv.fi> <20080826205916.GB11734@cs181140183.pp.htv.fi> <1219827609.30209.29.camel@spike.firmix.at> <1219843032.30209.51.camel@spike.firmix.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1219843032.30209.51.camel@spike.firmix.at> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1727 Lines: 41 Bernd Petrovitsch wrote: > If you "develop" an embedded system (which is partly system integration > of existing apps) to be installed in the field, you don't have that many > conceivable work loads compared to a desktop/server system. And you have > a fixed list of drivers and applications. Hah! Not in my line of embedded device. 32MB no-MMU ARM boards which people run new things and attach new devices to rather often - without making new hardware. Volume's too low per individual application to get new hardware designed and made. I'm seriously thinking of forwarding porting the 4 year old firmware from 2.4.26 to 2.6.current, just to get new drivers and capabilities. Backporting is tedious, so's feeling wretchedly far from the mainline world. > A usual approach is to run stress tests on several (or all) > subsystems/services/... in parallel and if the device survives it > functioning correctly, it is at least good enough. Per application. Some little devices run hundreds of different applications and customers expect to customise, script themselves, and attach different devices (over USB). The next customer in the chain expects the bits you supplied to work in a variety of unexpected situations, even when you advise that it probably won't do that. Much like desktop/server Linux, but on a small device where silly little things like 'create a process' are a stress for the dear little thing. (My biggest lesson: insist on an MMU next time!) -- Jamie -- 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/