From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [Bug #11201] kernel BUG at arch/x86/kernel/io_apic_64.c:357! Date: Sun, 10 Aug 2008 12:51:51 -0700 Message-ID: References: <489F31FC.9040104@zytor.com> Mime-Version: 1.0 Return-path: In-Reply-To: <489F31FC.9040104-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> (H. Peter Anvin's message of "Sun, 10 Aug 2008 11:22:52 -0700") Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "H. Peter Anvin" Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Dhaval Giani , Yinghai Lu "H. Peter Anvin" writes: > Eric W. Biederman wrote: >> "Rafael J. Wysocki" writes: >> >>> This message has been generated automatically as a part of a report >>> of recent regressions. >>> >>> The following bug entry is on the current list of known regressions >>> from 2.6.26. Please verify if it still should be listed and let me know >>> (either way). >> >> Yep. There is a patch in -mm. It seems the process is to wait for Thomas & >> Ingo to get back before we send this to Linus. >> > > Yes, unfortunately I still don't have enough testing resources to want to push > this upstream. I'm queuing it up for submission, though. No problem. I don't expect any problems as it is a simple reversion of the definition of NR_IRQS on x86_64 to what we had before everything was merged into irq_vectors.h and the x86_64 bits got lost. With the result that NR_IRQS varies in practice between 244 and 4096 depending on how many cpus you have. We have had NR_IRQS that large on x86_64 for a year or better now so I don't expect any practical problems. The long term fix will obviously be kill NR_IRQS. But that is not a 2.6.27 term project. Eric