Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758532AbXEYJkr (ORCPT ); Fri, 25 May 2007 05:40:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751163AbXEYJkl (ORCPT ); Fri, 25 May 2007 05:40:41 -0400 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:37157 "EHLO amd.ucw.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750941AbXEYJkk (ORCPT ); Fri, 25 May 2007 05:40:40 -0400 Date: Fri, 25 May 2007 11:40:16 +0200 From: Pavel Machek To: Linus Torvalds Cc: Nigel Cunningham , Romano Giannetti , Chris Wright , Chuck Ebbert , Linux Kernel Mailing List , stable@kernel.org, Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , Michael Krufky , akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, "Rafael J. Wysocki" Subject: Need suspend-to-ram maintainer Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Message-ID: <20070525094016.GJ9604@elf.ucw.cz> References: <20070524220017.GC9604@elf.ucw.cz> <20070524221743.GD9604@elf.ucw.cz> <20070524231852.GG9604@elf.ucw.cz> <1180058123.3997.91.camel@nigel.suspend2.net> <1180059605.3997.100.camel@nigel.suspend2.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.11+cvs20060126 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2515 Lines: 52 Hi! > > To answer the question, I guess the answer is that although they're > > different creatures, they have similarities. This is one of them, which > > is why I could make the mistake I did. Nothing in the issue being > > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus > > too much on the similarities, but that doesn't mean they're not there. > > I agree that the current bug is not unique to STR. In fact, I think Romano > tested both STD and STR, and both had the same bug with the 60s timeout. > > But what irritates me is that STR really shouldn't have _had_ that bug at > all. The only reason STR had the same bug as STD was exactly the fact that > the two features are too closely inter-twined in the kernel. And what do you expect? We have three people working on hibernation, and suspend-to-ram was created as "oh, if we do this, this, and this, we get get suspend-to-ram with existing code". > I agree that disk snapshotting is much harder. If we had a bug just in > that part, I wouldn't mind it so much. Getting hard problems wrong isn't > something you should be ashamed of. What I mind is that the _easier_ > problem got infected by all the bugs from the _harder_ issue. That just > makes me really really angry and frustrated. > > Look at it this way: if you designed a CPU, and you made the integer > code-path share everything with the floating point side, because "addition > is addition", and as a result the latency for the simple arithmetic and > logical ops in integer ALU was four cycles, what would you be? You'd be seriously overstaffed in FPU side, and seriously understaffed on ALU side. This is basically what happened here. I tell people to get hibernation to work _first_ because it is usually easier. And what does that mean? We need three people to work on suspend-to-RAM. Heck, we need at least _one_ person to work on suspend-to-RAM, but he needs to be listed in MAINTAINERS. With hibernation people trying to maintain suspend in their spare cycles, how do you expect suspend to work? Similar to hibernation, that's how it looks today. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/