Hi Duncan and Randy,
I tested Duncan's patch. It works for me with parameters "mpint=5,0,4,9".
On Sun, Jan 21, 2001 at 09:54:23PM -0700, Duncan Laurie wrote:
> The values to use depend on what your system is configured to use
> for the USB interrupt. This can be obtained by using the dump_pirq
Hi Duncan and Randy,
I tested Duncan's patch. It works for me with parameters "mpint=5,0,4,9".
On Sun, Jan 21, 2001 at 09:54:23PM -0700, Duncan Laurie wrote:
The values to use depend on what your system is configured to use
for the USB interrupt. This can be obtained by using the dump_pirq
> From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
>
> On Mon, 22 Jan 2001, Randy.Dunlap wrote:
>
> Hi Randy,
>
> Oops, I knew it was an STL2, but somehow couldn't get it right in the
> message.. It looks like they both use ServerWorks LE chipsets, do you
> know if the SBT2 has the same
On Mon, 22 Jan 2001, Randy.Dunlap wrote:
|
| (BTW, it's an STL2 board, not SBT2. And it's Randy, not Mr. Dunlap. :)
|
Hi Randy,
(I'll spare you the formality ;)
Oops, I knew it was an STL2, but somehow couldn't get it right in the
message.. It looks like they both use ServerWorks LE
Duncan Laurie wrote:
>
...
>
> The output you are looking for should look something like this:
>
> Device 00:0f.0 (slot 0): ISA bridge
> INTA: link 0x01, irq mask 0x0400 [10]
...
> Good luck, and feel free to send me the output from "dump_pirq"
> and "mptable" if it doesn't work..
Hi
Hi Duncan,
> From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
>
> Hi Petr,
>
> I didn't consider that your hardware would have subtle differences
> than Mr. Dunlap's Intel SBT2 board, but these could have made the
> hard-coded values in the patch invalid. So instead try the attached
> patch,
Hi Duncan,
From: Duncan Laurie [mailto:[EMAIL PROTECTED]]
Hi Petr,
I didn't consider that your hardware would have subtle differences
than Mr. Dunlap's Intel SBT2 board, but these could have made the
hard-coded values in the patch invalid. So instead try the attached
patch, and this
Duncan Laurie wrote:
...
The output you are looking for should look something like this:
Device 00:0f.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x0400 [10]
...
Good luck, and feel free to send me the output from "dump_pirq"
and "mptable" if it doesn't work..
Hi Duncan,
On Mon, 22 Jan 2001, Randy.Dunlap wrote:
|
| (BTW, it's an STL2 board, not SBT2. And it's Randy, not Mr. Dunlap. :)
|
Hi Randy,
(I'll spare you the formality ;)
Oops, I knew it was an STL2, but somehow couldn't get it right in the
message.. It looks like they both use ServerWorks LE
On Thu, 18 Jan 2001, Petr Matula wrote:
| On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
| > There may be bogus data in the PIRQ table as well, which is why this
| > explicitly routes the interrupt & sets the ELCR. If you enable DEBUG
| > in pci-i386.h and re-send the dmesg
IL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: int. assignment on SMP + ServerWorks chipset
>
...
> This may actually be an MP BIOS bug...
Yes, I was also thinking this. I'll check with some other
people on it tomorrow.
Thanks,
~Randy
___
|r
];
[EMAIL PROTECTED]
Subject: RE: int. assignment on SMP + ServerWorks chipset
...
This may actually be an MP BIOS bug...
Yes, I was also thinking this. I'll check with some other
people on it tomorrow.
Thanks,
~Randy
___
|randy.dunlap_at_intel.com
On Thu, 18 Jan 2001, Petr Matula wrote:
| On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
| There may be bogus data in the PIRQ table as well, which is why this
| explicitly routes the interrupt sets the ELCR. If you enable DEBUG
| in pci-i386.h and re-send the dmesg output I
On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
> There may be bogus data in the PIRQ table as well, which is why this
> explicitly routes the interrupt & sets the ELCR. If you enable DEBUG
> in pci-i386.h and re-send the dmesg output I will look it over.
I tied your patch. dmesg
On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
There may be bogus data in the PIRQ table as well, which is why this
explicitly routes the interrupt sets the ELCR. If you enable DEBUG
in pci-i386.h and re-send the dmesg output I will look it over.
I tied your patch. dmesg
On Wed, Jan 17, 2001 at 01:33:42PM -0800, Linus Torvalds wrote:
> Did you also remove the two lines that disabled pirq routing if an IO-APIC
> was enabled?
Yesterday not, today yes. But it's the same.
> > Kernel with these changes can't detect my SCSI drive. It prints these messages
> > in
On Wed, 17 Jan 2001, Petr Matula wrote:
>
> I did the changes above to 2.4.0 source.
Did you also remove the two lines that disabled pirq routing if an IO-APIC
was enabled?
> Kernel with these changes can't detect my SCSI drive. It prints these messages
> in cycle:
Which SCSI adapter is
There is a interrupt transaction delay imposed on all interrupts of 600ns
spacing. It can be turned on/off but this may not help.
Cheers,
On Wed, 17 Jan 2001, Petr Matula wrote:
> On Mon, Jan 15, 2001 at 08:49:56PM -0800, Linus Torvalds wrote:
> > So what I _think_ is the correct change is
On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
> Here's a patch to find & correct this entry on boot. Its not pretty,
> and should ONLY be used to verify this particular fix--any real solution
> will have to be done in the BIOS. (there doesn't seem to be an easy way
> to alter
On Mon, Jan 15, 2001 at 08:49:56PM -0800, Linus Torvalds wrote:
> So what I _think_ is the correct change is to do roughly this in
> arch/i386/kernel/pci-irq.c:
>
> - in pcibios_fixup_irqs(), remove the
>
> #idef CONFIG_X86_IO_APIC
> ...
> #endif
>
>section
On Mon, Jan 15, 2001 at 08:49:56PM -0800, Linus Torvalds wrote:
So what I _think_ is the correct change is to do roughly this in
arch/i386/kernel/pci-irq.c:
- in pcibios_fixup_irqs(), remove the
#idef CONFIG_X86_IO_APIC
...
#endif
section entirely.
-
On Tue, Jan 16, 2001 at 06:39:46PM -0700, Duncan Laurie wrote:
Here's a patch to find correct this entry on boot. Its not pretty,
and should ONLY be used to verify this particular fix--any real solution
will have to be done in the BIOS. (there doesn't seem to be an easy way
to alter
There is a interrupt transaction delay imposed on all interrupts of 600ns
spacing. It can be turned on/off but this may not help.
Cheers,
On Wed, 17 Jan 2001, Petr Matula wrote:
On Mon, Jan 15, 2001 at 08:49:56PM -0800, Linus Torvalds wrote:
So what I _think_ is the correct change is to
On Wed, 17 Jan 2001, Petr Matula wrote:
I did the changes above to 2.4.0 source.
Did you also remove the two lines that disabled pirq routing if an IO-APIC
was enabled?
Kernel with these changes can't detect my SCSI drive. It prints these messages
in cycle:
Which SCSI adapter is this?
On Wed, Jan 17, 2001 at 01:33:42PM -0800, Linus Torvalds wrote:
Did you also remove the two lines that disabled pirq routing if an IO-APIC
was enabled?
Yesterday not, today yes. But it's the same.
Kernel with these changes can't detect my SCSI drive. It prints these messages
in cycle:
On Tue, 16 Jan 2001, [EMAIL PROTECTED] wrote:
>
> On Mon, 15 Jan 2001, Randy.Dunlap wrote:
> >
> > A Linux-USB user (pem@ = Petr) reported that USB (OHCI) wasn't
> > working on his Intel STL2 system. This system uses a ServerWorks
> > chipset, hence the OHCI part.
>
> Does it work with
On Tue, 16 Jan 2001, [EMAIL PROTECTED] wrote:
On Mon, 15 Jan 2001, Randy.Dunlap wrote:
A Linux-USB user (pem@ = Petr) reported that USB (OHCI) wasn't
working on his Intel STL2 system. This system uses a ServerWorks
chipset, hence the OHCI part.
Does it work with "noapic"?
> And if anybody else understands pirq routing, speak up. It's a black art.
>
I have some experience with PIRQ and Serverworks, but I missed the first
bit of this discussion - can someone catch me up?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, 15 Jan 2001, Dunlap, Randy wrote:
>
> Thanks for looking into this. I'll be out of touch for
> the rest of this week, but Petr ([EMAIL PROTECTED])
> should be able to test patches that Ingo comes up with.
>
> > Ok. That means that the problem is that we _should_ look at
> > the pirq
On Mon, 15 Jan 2001, Dunlap, Randy wrote:
Thanks for looking into this. I'll be out of touch for
the rest of this week, but Petr ([EMAIL PROTECTED])
should be able to test patches that Ingo comes up with.
Ok. That means that the problem is that we _should_ look at
the pirq table
And if anybody else understands pirq routing, speak up. It's a black art.
I have some experience with PIRQ and Serverworks, but I missed the first
bit of this discussion - can someone catch me up?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
31 matches
Mail list logo
