APIC support on uniprocessor machines

[James Tabor]

Hi All,
This may not be related to a problem I'm having. I can not load cromwell
uhci driver. Ne2000 does load but unable to ping anything out side the box.
Both share irq 0xb or 11. I noticed we have apic and ioapic in 'mp'. How hard
would it be to port them over to 'up' for supporting uniprocessor. I could
try but the group mood ATM is fairly poor. Other words I would not like to
piss off anyone.

Using APIC would fix interrupt sharing problems and expand Ros to a higher
OS level.

Thanks,
James


ps I did disable hive loading for the ne2000 but since the board is still in
the box, I guess it's causing problems.

[Aleksey Bragin]

    Hi James,
Really cromwell uhci isn't supposed to correctly load now (though it does to 
some extent now, thanks to hpoussin's work on resources assignment).

But, in fact, despite both uhci and ohci dprint they are using interrupts, 
don't believe your eyes. They don't do it for real :-).
OHCI has a workaround, which uses another thread (needed anyway, even if 
real interrupt is used), and thus it's doing it like 'in polled mode'.
UHCI doesn't have any workarounds at all, it's really version I adapted from 
Linux 2.5 usb code. But it's still way better than to invent wheel from 
scratches.

So, APIC would be a great thing, but right now (until I or someone else does 
an interrupt handler in uhci) it won't make uhci better or worse :-)

WBR,
Aleksey.
----- Original Message ----- 
From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
To: "ReactOS Development List" <ros-dev(a)reactos.com>
Sent: Tuesday, May 24, 2005 7:41 AM
Subject: [ros-dev] APIC support on uniprocessor machines


>   Hi All,
>  This may not be related to a problem I'm having. I can not load cromwell
>  uhci driver. Ne2000 does load but unable to ping anything out side the 
>  box.
>  Both share irq 0xb or 11. I noticed we have apic and ioapic in 'mp'. How 
>  hard
>  would it be to port them over to 'up' for supporting uniprocessor. I could
>  try but the group mood ATM is fairly poor. Other words I would not like to
>  piss off anyone.
>
>  Using APIC would fix interrupt sharing problems and expand Ros to a higher
>  OS level.
>
>  Thanks,
>  James
>
>
>  ps I did disable hive loading for the ne2000 but since the board is still 
>  in
>  the box, I guess it's causing problems.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev

[Hartmut Birr]

Hi,   

if your machine can run M$ windows in APIC mode, you can use the SMP
build. For using the apic mode, the bios must provide an MP structure.
The acpi structures doesn't contain the wiring between the apic and the
physical interrupt lines. But sharing of interrupts in non apic mode
should also work. I've a test machine which does share one interrupt
with two scsi controllers and one network card. The scsi cards work
perfectly. The nic driver is loaded, but it didn't work properly. I
think this has nothing to do with the interrupt.

- Hartmut

[James Tabor]

Hi!
Hartmut Birr wrote:
>   Hi,   
>  
>  if your machine can run M$ windows in APIC mode, you can use the SMP
>  build. For using the apic mode, the bios must provide an MP structure.
>  The acpi structures doesn't contain the wiring between the apic and the
>  physical interrupt lines. But sharing of interrupts in non apic mode
>  should also work. I've a test machine which does share one interrupt
>  with two scsi controllers and one network card. The scsi cards work
>  perfectly. The nic driver is loaded, but it didn't work properly. I
>  think this has nothing to do with the interrupt.
>  
>  - Hartmut
>   
I'm run Linux with APIC uniprocessor compiled w/o smp support. But would
that make a difference? I'll try compiling smp to see.

Here is a interrupt list dump from linux,

root@rosbox:/proc# cat interrupts
            CPU0
   0:  688709406    IO-APIC-edge  timer
   1:     227899    IO-APIC-edge  i8042
   3:   37547817    IO-APIC-edge  serial
   7:    2888974    IO-APIC-edge  parport0
   9:          1   IO-APIC-level  acpi
  12:    3308666    IO-APIC-edge  i8042
  14:     345459    IO-APIC-edge  ide0
  15:         25    IO-APIC-edge  ide1
  17:         21   IO-APIC-level  ide2
  19:    7669945   IO-APIC-level  eth0
  21:          0   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
  22:     728139   IO-APIC-level  VIA8233
NMI:          0
LOC:  688695128
ERR:          0
MIS:          0

With apic you can reassign irq and do not need to share them. The only
one is usb and thats for good reason.

Thanks Hartmut,
James

[Hartmut Birr]

James Tabor wrote:

>   Hi!
>  Hartmut Birr wrote:
>
> >   Hi,  
> >  if your machine can run M$ windows in APIC mode, you can use the SMP
> >  build. For using the apic mode, the bios must provide an MP structure.
> >  The acpi structures doesn't contain the wiring between the apic and the
> >  physical interrupt lines. But sharing of interrupts in non apic mode
> >  should also work. I've a test machine which does share one interrupt
> >  with two scsi controllers and one network card. The scsi cards work
> >  perfectly. The nic driver is loaded, but it didn't work properly. I
> >  think this has nothing to do with the interrupt.
> >
> >  - Hartmut
> >  
>  I'm run Linux with APIC uniprocessor compiled w/o smp support. But would
>  that make a difference?  
No, that is the same. Sorry, If I assumed that you are using windows. :-)

>   I'll try compiling smp to see.
>  
I think, it is possible to use the smp hal with the non smp kernel to
enable the apic support. There are only some little changes in
ntoskrnl\ke\i386\irq.c necessary.

- Hartmut