> I don't know of a good version yet. I so far don't know if there ever
> was one. This could even be a bug in the PCI hardware, or the way the
> BIOS on this system on a board configured the PCI controller. Maybe I
> should go back and try a 2.4 kernel.
>
> > Hope some of that helps :)
>
> We
> -Original Message-
> From: Ashok Raj [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 01, 2005 3:27 PM
> To: Protasevich, Natalie
> Cc: Ashok Raj; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> linux-k
> Hi Natalie,
>
> sorry for the late catchup...
>
> Just to make sure we use the cpu maps properly here is the
> current definition iam not sure if you are breaking any of
> these assumptions, cause if you do you will break existing
> implementations... so pardon for the verbosity.
>
> cpu_p
> Protasevich, Natalie wrote:
> > > > +#ifdef CONFIG_HOTPLUG_CPU
> > > > + if (cpu_online(cpu)) {
> > > > +#else
> > > > if (cpu_online(cpu) || !cpu_present(cpu)) {
> > > > +#endif
> >
> > +#ifdef CONFIG_HOTPLUG_CPU
> > + if (cpu_online(cpu)) {
> > +#else
> > if (cpu_online(cpu) || !cpu_present(cpu)) {
> > +#endif
> > ret = -EINVAL;
> > goto out;
> > }
>
> Why this change? I think the cpu_present check is needed for
> ppc64 since it has non-pr
> Hi,
> On Wed, 2005-08-31 at 20:13 +0800,
> [EMAIL PROTECTED] wrote:
> > Current IA32 CPU hotplug code doesn't allow bringing up processors
> > that were not present in the boot configuration.
> > To make existing hot plug facility more practical for physical hot
> > plug, possible processors s
> We should probably also not to try to boot disabled cpus in
> smp_boot_cpus()...
>
> --Mika
>
Good point, probably by not setting phys_cpu_present_map for those in
MP_processor_info()...
Thanks,
--Natalie
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
> Hallo Natalie,
>
> On Wednesday 31 August 2005 14:13,
> [EMAIL PROTECTED] wrote:
> > Current IA32 CPU hotplug code doesn't allow bringing up processors
> > that were not present in the boot configuration. To make
> existing hot
> > plug facility more practical for physical hot plug, possible
> On Thursday 04 August 2005 02:22 am, Andi Kleen wrote:
> > On Thu, Aug 04, 2005 at 12:05:50AM -0700, James Cleverdon wrote:
> > > diff -pruN 2.6.12.3/arch/i386/kernel/acpi/boot.c
> > > n12.3/arch/i386/kernel/acpi/boot.c ---
> > > 2.6.12.3/arch/i386/kernel/acpi/boot.c 2005-07-15
> 14:18:57.00
> On Thursday 04 August 2005 02:22 am, Andi Kleen wrote:
> > On Thu, Aug 04, 2005 at 12:05:50AM -0700, James Cleverdon wrote:
> > > diff -pruN 2.6.12.3/arch/i386/kernel/acpi/boot.c
> > > n12.3/arch/i386/kernel/acpi/boot.c ---
> > > 2.6.12.3/arch/i386/kernel/acpi/boot.c 2005-07-15
> 14:18:57.00
> On Wed, 10 Aug 2005, Protasevich, Natalie wrote:
>
> > our systems we are just about to use up all 224 interrupts, but not
> > quiet.
> > I have to mention that as far as I know Zwane is about to
> release his
> > vector sharing mechanism, he had it im
> After sleeping on it, maybe the original code can be patched
> without having to hack assign_irq_vector(), etc. How about:
>
> --- io_apic.c 2005-08-11 10:14:33.564748923 -0700
> +++ io_apic.c.new 2005-08-11 10:15:55.412331115 -0700
> @@ -617,7 +617,7 @@ int gsi_irq_sharing(int gsi)
>
> > The only problem is here:
> >
> > + if (i < NR_IRQS) {
> > + gsi_2_irq[gsi] = i;
> > + printk(KERN_INFO "GSI %d sharing vector 0x%02X and IRQ
> > %d\n",
> > + gsi, vector, i);
> > + return i;
> > + }
> > +
> > + i = next_irq++;
> >
>
> > int gsi_irq_sharing(int gsi)
> > {
> > int i, irq, vector;
> >
> > BUG_ON(gsi >= NR_IRQ_VECTORS);
> >
> > if (platform_legacy_irq(gsi)) {
> > gsi_2_irq[gsi] = gsi;
> > return gsi;
> > }
> >
> > if (gsi_2_irq[gsi] != 0xFF)
>
> Due to some device driver issues, I built this iteration of
> the patch vs. 2.6.12.3.
>
> (Sorry about the attachment, but KMail is still word wrapping inserted
> files.)
>
> Background:
>
> Here's a patch that builds on Natalie Protasevich's IRQ
> compression patch and tries to work for MPS
> > Le Lundi 25 Juillet 2005 22:44, Alan Stern a écrit :
> > >
> > > Now that's strange. When you plug the high-speed device into the
> > > integrated ports, which IRQ counter changes? Since
> nothing is using
> > > IRQ 21, it should be disabled and its counter should remain
> > > constant.
> > Now that we know which is the offending device, it should
> be easy to
> > find out why the IRQ assignments go wrong. That certainly
> needs to be
> > fixed, even though Michel's problem appears to be solved.
>
> Well, it's solved by currently giving me the choice between
> no USB 2.0 an
> > On the other hand, _something_ was generating an interrupt request
> > that got mapped to IRQ 21 by the hardware. And these
> requests do seem
> > to be associated with USB activity. Maybe the EHCI
> controller is responsible?
> > One of your postings showed both uhci_hcd:usb2 and ehci_hc
> >Michel,
> >When you get chance, maybe you could boot the OS that used to work
for you (you mentioned 2.4) and provide the boot trace and
/proc/interrupts for comparison.
> # cat /proc/interrupts - 2.4:
>CPU0
> 0: 32095IO-APIC-edge timer
> 1:968IO-APIC-edge
> Le Lundi 11 Juillet 2005 22:58, Michel Bouissou a écrit :
> >
> > Oh no :-(
>
> Well, I give up for tonight :-(
>
> This time I rebooted with the mouse disabled in BIOS, with
> the usb-handoff option, with the scanner unplugged... And it
> went wrong simply by itself.
> "irq 21: nobody cared
> Le Lundi 11 Juillet 2005 20:36, Alan Stern a écrit :
> > It's also possible that the UHCI controllers are generating the
> > unwanted interrupt requests. You should make sure that Legacy USB
> > Support is turned off in your BIOS settings.
>
> My motherboard both holds USB 1.1 and USB 2.0 con
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Michel Bouissou
> Sent: Sunday, July 10, 2005 2:11 AM
> To: linux-kernel@vger.kernel.org
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
>
> Hi
> Hi there,
>
> I use a Gigabyte GA7-VAXP motherboard that has been fine for
> more than 2 years with 2.4 series kernels, and that gives
> trouble with 2.6.12 (and previous) kernels.
>
> The problem seems to sit between the UP IO-APIC and USB
> uhci_hcd driver.
>
> The GA7-VAXP MB is equipped
> Hm, I did not get any answer to my last report last week.
> Didn't you get it?
>
> There are still the same errors in kernel 2.6.13rc2 as in
> 2.6.13rc1. So I've attached an up to date syslog and the last
> error report below.
>
Hi Alexander,
To me, it looks like both IDE channels get wrong
> I've been having interrupt problems. 2.6.12 worked fine, but
> soon after it got broken and was still broken just now that I
> checked git version.
>
> Interrupts get somehow misrouted.
>
> Here is a part from the syslog showing the problem:
>
> Jul 3 13:17:09 kohtala kernel: USB Universal
triggers sysfs node for this processor.
Thanks,
--Natalie
-Original Message-
From: Zwane Mwaikambo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 12, 2005 6:08 AM
To: Li Shaohua
Cc: lkml; ACPI-DEV; Len Brown; Pavel Machek; Andrew Morton; Protasevich,
Natalie; Ryan Harper
Subject: Re: [PATCH
> I forgot to mention that while working on the patch,
> I found a problem with ACPI driver while counting number of records
> in acpi_table_parse_madt_family() (drivers/acpi/tables.c).
> It always returns 0 for the number of records, so this should be
> fixed for my patch to work properly, si
.6.11.6-mm/init/main.c linux-2.6.11.6-HC/init/main.c
--- linux-2.6.11.6-mm/init/main.c 2005-04-06 23:08:21.0
-0400
+++ linux-2.6.11.6-HC/init/main.c 2005-04-12 08:46:54.0
-0400
@@ -684,7 +684,9 @@ static int init(void * unused)
* we're essentially up and running
28 matches
Mail list logo
