> 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 :)
>
>
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 :)
Well
> -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.
>
>
> 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
> 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
> 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
> 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,
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
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 body of a
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 should be
+#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-present cpus in
Protasevich, Natalie wrote:
+#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
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.
-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-kernel@vger.kernel.org; [EMAIL
> 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
>
> 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
>
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.0
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.0
> 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++;
> >
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++;
That means for any IRQ
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)
*
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 implemented and working
for i386
(I tested
> > 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
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 boots as
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)
return
> > 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.
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. Does this mean
> > 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
> > 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
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_hcd:usb4
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 and IO-APIC,
> >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
> 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
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
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!
The
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
> -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
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 with an
-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 there,
> 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
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 IRQ.
> 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
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 Host
ode 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 1/6]sep initializing rew
> 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,
C/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. Get rid of the
* initmem segments and start the user-mode stuff..
*/
+#infdef CONFIG_HOTPLUG_CPU
free_initmem();
+#endif
unl
;
numa_default_policy();
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Protasevich,
Natalie
Sent: Tuesday, April 12, 2005 11:57 AM
To: Zwane Mwaikambo; Li Shaohua
Cc: Andrew Morton; Len Brown; ACPI-DEV; Ryan Harper;
[EMAIL PROTECTED]; Pavel Machek; Andi
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, since
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 1/6]sep initializing rework
56 matches
Mail list logo
