Text 472, 147 rader
Skriven 2007-02-09 21:37:08 av Mike Luther (1:117/3001.0)
     Kommentar till en text av Alan Hess
Ärende: pci.exe output
======================
Alan ..

 AH> This is the output from pci.exe.  It shows four
 AH> devices sharing irq 11.  Any way I can change some of 
 AH> them to different irqs?  Perhaps that would help with 
 AH> my Radeon-Expert Mouse problem.

Does your motherboard BIOS support hard assignment of the IRQ's to a given PCI
slot as part of its capabilities?  If it does then you may be able to force a
different IRQ for an item in a given PCI slot on your motherboard.  Ordinarily,
if memory is correct, your mouse ought to be normally looking at IRQ12.  Thus
the devices sharing IRQ 11 ought not to be a conflict issue there.

In line with this, your below looks like an SBLive 5.1 PCI audio card.

 AH>  Bus 0 (PCI), Device Number 9, Device Function 0
 AH>  Vendor 1102h Creative Labs
 AH>  Device 0002h EMU10K1 Audio Chipset (SB Live!)

 AH>  System IRQ 11, INT# A

If so, then either of two possible 'solutions' for IRQ sharing on it might help
you.  First is the above.  I try to work with the SBLive 5.1 card as an IRQ10
operation if possible.  If you cannot 'force' assign that to this card in the
slot it is in, you may be able to move the card to another slot.  Usually,
moving a PCI card to another slot tends to coax a motherboard to grant it a
different IRQ.  If you can one way or another do this, you may help get a
possible conflict for the audio card driver out of harm's way.  The audio card
IRQ conflict deal can really hurt things, especially if it is in conflict with
a network card.

The same thinking goes for the SCSI card .. if it is a card.  If it is an
on-board SCSI controller and this is the boot drive you might note.

 AH>  Bus 0 (PCI), Device Number 11, Device Function 0
 AH>  Vendor 1022h Advanced Micro Devices (AMD)
 AH>  Device 2020h AM53C974 SCSI Bridge (AKA Qlogic 
 AH> Fast!SCSI Basic, Tekram DC-390)
 AH>  Command 0087h (I/O Access, Memory Access, BusMaster, Wait Cycles)
 AH>  Status 0200h (Medium Timing)
 AH>  Revision 10h, Header Type 00h, Bus Latency Timer 20h
 AH>  Minimum Bus Grant 04h, Maximum Bus Latency 28h
 AH>  Self test 00h (Self test not supported)
 AH>  PCI Class Storage, type SCSI
 AH>  Address 0 is an I/O Port : D800h..D87Fh
 AH>  System IRQ 11, INT# A
 AH>  Expansion ROM of 64 KiB decoded by this card, currently disabled

I know nothing about the Tekram product.  But for the Adaptec PCI SCSI cards,
the raw on-board Adaptec BIOS when accessed by their <CTRL A> at boot time card
setup force effort can be specifically set to a different IRQ than 'normal' if
needed.  Getting this card off IRQ11 by the first technique, or swapping it in
a different PCI slot, or .. by forcing the IRQ to other than IRQ11, but not
IRQ10 if that is what you want on the SBLive audion card will usually help get
rid of this error vector.

The NIC IRQ seems out of the way at this point...

 AH>  Bus 0 (PCI), Device Number 13, Device Function 0
 AH>  Vendor 8086h Intel Corporation
 AH>  Device 1229h 82559 Fast Ethernet Multifunction 
 AH> PCI/CardBus Controller (C-step)

 AH>  System IRQ 5, INT# A

The IDE IRQ's seem normal at this point.,,

 AH>  Bus 0 (PCI), Device Number 17, Device Function 1
 AH>  Vendor 1106h VIA Technologies Inc
 AH>  Device 0571h VT82xxxx EIDE Controller (All VIA Chipsets)
 AH>    Primary   Channel is at I/O Port 01F0h and IRQ 14
 AH>    Secondary Channel is at I/O Port 0170h and IRQ 15

 AH>  Subsystem ID 05711106h VT82Cxxxx EIDE Controller (All
 AH> VIA Chipsets) (Generic ID)

 AH>  System IRQ (disabled), INT# A

The USB controllers may be at issue in that they seem to be an on-board
chipset.  If so, doing anything to it is going to likely by an issue ...

 AH>  Bus 0 (PCI), Device Number 17, Device Function 2
 AH>  Vendor 1106h VIA Technologies Inc
 AH>  Device 3038h VT8233A USB Controller

 AH>  System IRQ 11, INT# D

 AH>  Bus 0 (PCI), Device Number 17, Device Function 3
 AH>  Vendor 1106h VIA Technologies Inc
 AH>  Device 3038h VT8233A USB Controller

 AH>  System IRQ 11, INT# D

And your PCI slot Matox video card is already on IRQ10.  So obviously you don't
want it on the same IRQ as your SBLive.  Thus ..

 AH>  Bus 1 (AGP), Device Number 0, Device Function 0
 AH>  Vendor 102Bh Matrox Graphics Inc
 AH>  Device 0525h MGA-G400/450 Chipset

 AH>  System IRQ 10, INT# A

Looking at life in the fast lane, your choices for things boil down to the
following.

    IRQ 0  - Non Mask Interrup (reserved).
    IRQ 1  - Keyboard.
    IRQ 2  - Bootstrapped to IRQ 9 thus paired with it - whatever.
    IRQ 3  - COM2 normally - If not in use can be used otherwise.
    IRQ 4  - COM2 normally - If not in use can be used otherwise.
    IRQ 5  - In use for the NIC which ought to be fine.
    IRQ 6  - Floppy controller.
    IRQ 7  - LPT1 printer use normally.
    IRQ 8  - Real Time Clock (reserved).
    IRQ 9  - Looks available in your case .. I usually run SCSI here,
    IRQ 10 - In use for the VIA video chipset .. usually OK.
    IRQ 11 - *CAN* be shared for USB if device driver written properly.
    IRQ 12 - Mouse (reserved - normally unless serial mouse).
    IRQ 13 - Numeric Co-processor (reserved).
    IRQ 14 - Normally for IDE controller #1 as you report.
    IRQ 15 - Normally for IDE controller #2 as you report.

If you are not using the second IDE controller and can free that IRQ 15 up with
your BIOS setup, that will make one IRQ free for something else. We see that
IRQ then available at times for the SCSI controller, or for the video card. 
Which would free up the IRQ 10 you are using for the Matrox video card for
other use.  That is what I see used at times for the SBLive 5.1 card on many
boxes.  Which, with the SCSI controller on IRQ 9 makes that all go away from
the IRQ 11 gambit.

And .. if you are using a SERIAL mouse, SOMETIMES the OS/2 operating system
cannot 'find' it unless you specifically comment the MOUSE driver in CONFIG.SYS
to tell it to look for a serial mouse.  With some mice but not others, as I
have seen.  Forcing that with some mice on a serial port can stop this in some
systems.  But usually you wind up able to boot to the Desktop but just get no
mouse working at all.


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001




--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)