Re: int. assignment on SMP + ServerWorks chipset

2001-01-24 Thread Petr Matula
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

RE: int. assignment on SMP + ServerWorks chipset

2001-01-22 Thread Dunlap, Randy
> 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 problem

Re: int. assignment on SMP + ServerWorks chipset

2001-01-22 Thread Duncan Laurie
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 chipsets

Re: int. assignment on SMP + ServerWorks chipset

2001-01-22 Thread Randy.Dunlap
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 Dunc

RE: int. assignment on SMP + ServerWorks chipset

2001-01-22 Thread Dunlap, Randy
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

Re: int. assignment on SMP + ServerWorks chipset

2001-01-21 Thread Duncan Laurie
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

RE: int. assignment on SMP + ServerWorks chipset

2001-01-21 Thread Dunlap, Randy
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 _

Re: int. assignment on SMP + ServerWorks chipset

2001-01-18 Thread Petr Matula
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 o

Re: int. assignment on SMP + ServerWorks chipset

2001-01-17 Thread Petr Matula
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

Re: int. assignment on SMP + ServerWorks chipset

2001-01-17 Thread Linus Torvalds
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 th

Re: int. assignment on SMP + ServerWorks chipset

2001-01-17 Thread Andre Hedrick
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

Re: int. assignment on SMP + ServerWorks chipset

2001-01-17 Thread Petr Matula
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 sp

Re: int. assignment on SMP + ServerWorks chipset

2001-01-17 Thread Petr Matula
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 entire

RE: int. assignment on SMP + ServerWorks chipset

2001-01-16 Thread Duncan Laurie
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 "n

Re: int. assignment on SMP + ServerWorks chipset

2001-01-15 Thread Tim Hockin
> 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 mess

RE: int. assignment on SMP + ServerWorks chipset

2001-01-15 Thread Linus Torvalds
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