How do I "see" my USB PCI card?

[root.veg]

Just bought a new USB 2.0 PCI card. Why? because my motherboard is so old it only has pins for two USB 1.0 ports, and the wires from the USB ports in my case don't stretch! Also, the printer I've just bought is an all-in-one (HP PSC 1110) which scans, so the faster USB 2.0 should come in handy. Also bought a USB flash drive.

I've managed to get the printer and the flash drive to work on my laptop, running Fedora Core 1. Flash drive just works as /dev/sda1, and I can mount it OK. Kudzu and the CUPS setup program simply detected the printer OK, and I've printed a test page OK. So I know how they work.

Problem is, for my main box (running Debian testing) I can't even get as far as "seeing" the USB ports. Trying a

mount /dev/sda1 /usb

gives me "sda1 is not a valid block device". The hpoj driver setup program won't detect the printer/scanner.

from cat /proc/pci :

Bus 0, device 4, function 2:
USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 1).
Master Capable. Latency=32.
I/O at 0xd400 [0xd41f].
Bus 0, device 4, function 3:
Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 2).
IRQ 9.

(that looks like the onboard USB 1.0), then:

Bus 0, device 10, function 0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ ( rev 16).
IRQ 5.
Master Capable. Latency=32. Min Gnt=32.Max Lat=64.
I/O at 0xd000 [0xd0ff].
Non-prefetchable 32 bit memory at 0xd5800000 [0xd58000ff].
Bus 0, device 11, function 0:
Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 4).
IRQ 10.
Master Capable. Latency=32. Min Gnt=2.Max Lat=20.
I/O at 0xb800 [0xb81f].
Bus 0, device 11, function 1:
Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 1).
Master Capable. Latency=32.
I/O at 0xb400 [0xb407].
Bus 0, device 12, function 0:
USB Controller: NEC Corporation USB (rev 65).
IRQ 11.
Master Capable. Latency=32. Min Gnt=1.Max Lat=42.
Non-prefetchable 32 bit memory at 0xd5000000 [0xd5000fff].
Bus 0, device 12, function 1:
USB Controller: NEC Corporation USB (#2) (rev 65).
IRQ 10.
Master Capable. Latency=32. Min Gnt=1.Max Lat=42.
Non-prefetchable 32 bit memory at 0xd4800000 [0xd4800fff].
Bus 0, device 12, function 2:
USB Controller: NEC Corporation USB 2.0 (rev 2).
IRQ 5.
Master Capable. Latency=32. Min Gnt=16.Max Lat=34.
Non-prefetchable 32 bit memory at 0xd4000000 [0xd40000ff].
Bus 1, device 0, function 0:
VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev 1 64).
IRQ 11.
Master Capable. Latency=248. Min Gnt=5.Max Lat=1.
Non-prefetchable 32 bit memory at 0xd6000000 [0xd6ffffff].
Prefetchable 32 bit memory at 0xd8000000 [0xdfffffff].

See how the ethernet card and graphic card IRQs clash with the USB entries.

I've tried changing the PCI IRQ settings in the BIOS, but you can only change the three PCI slots.

My problem seems to be that whenever I change the IRQ for the USB card, the IRQ for the AGP graphics card always changes so it's the same. But I don't have control over the AGP IRQ, so I'm stumped.

Phew... long post - any ideas?

[bwkaz]

Move the USB card to a different slot?

The PCI controller has only 4 interrupt pins (INTA through INTD). Each of these pins maps through to each slot. But each slot "shifts" the pins by one space, so that a PCI device that uses its device INTA pin will map to either INTA, INTB, INTC, or INTD on the controller, depending on which slot it gets put into.

Most devices use device INTA.

The upshot of all this is, whatever PCI controller INT pin your AGP card is using is mapping to the same pin that your USB card is using. When you change BIOS settings, you're changing which of INTA through INTD on the controller maps to which IRQ line on the APIC (or XT-PIC). If both your AGP and USB cards are using INTC on the controller, then you can't change which IRQ they map to individually, except by changing the slot that your USB card is in.

[root.veg]

excellent info. I'll try it tonight if possible.

[root.veg]

Hmm... I seem to have solved this problem and created a few more at the same time.

The good news is that bwkaz was right - changing the USB card to another slot does the trick: no IRQ clashes. I've now got the USB card working so that hotplug detects when I connect the flash drive or the printer/scanner. I've even successfully scanned using scanimage!

BUT...

I only have three PCI slots, and I want to use them all (network card, sound card, USB card). Whichever card goes in the top slot (nearest the AGP slot) *always* gives an IRQ clash with the NVidia card in the AGP slot. So the only way I can use the USB card is by taking the soundcard out! Otherwise I get strange graphic weirdness when, for instance, playing Quake3. That's problem (1).

Problem (2) is that I dutifully rolled my own 2.6.6 kernel, as the printer/scanner driver needed more recent than 2.4.18. Went OK, most things I needed were compiled straight into the kernel. Problem is that anything module-related seems not to work now. e.g. lsmod gives an error message something like:

QM_MODULES not enabled

depmod gives "unresolved symbols" errors for quite a few modules (possibly all, I'm not sure).

Problem (3) is that when I try to recompile the NVidia driver to match my new kernel, it tells me that /lib/modules/2.6.6/build/include/modversions doesn't exist, but I've never had this problem before, because the kernel headers are already there from the main kernel compile. Installing the 2.6.6 kernel-headers does no good either. Also, using the non-accelerated "nv" driver included with X doesn't do any good either.

Finally, problem (4) is that I can't ssh or ping my box from work right now, despite having tested the networking last night. This is quite worrying... although my house can't have burned down yet because I can reach my firewall and my mail/webserver box...

Ack!

It's a big mess and there's no-one to blame except me and my head-first kernel-meddling tendencies. Any thoughts would be welcome before I get home in about ten hours and get stuck in!

I reckon I can handle the kernel stuff, but that PCI IRQ business is going to be the showstopper I reckon...

[danimal1009]

Originally posted by root.veg
How do I "see" my USB PCI card?
Open up your eyes and look at it! :D
Sorry, I couldn't resist. :)

[root.veg]

hehe, very funny, kick a guy when he's down, won't you (well without network connection and a b0rked box) :D

After a quick STFW, I have found out that QM_MODULES is strictly old-hat, 2.4 kernel only, and that I need to update my module utilities... preferrably BEFORE compiling a new shiny 2.6 kernel. And I probably need the latest NVidia drivers. Maybe I'll just boot back to my 2.4 kernel and start again :rolleyes:

That's what you get for being impatient, I guess.

However, that's probably not going to sort out my IRQ nightmare in the long run. Can you shuffle IRQs around in linux, or are they set in stone once the BIOS hands over to Linux for booting?

[bwkaz]

You can't move devices between IRQs at runtime, no (at least not that I know of).

However, you can try to turn on IO-APIC support (not ACPI, that's different), to get 32 IRQs instead of the measly 16 that you get with the ancient XT-PIC interrupt controllers.

In the kernel config, it's Processor type and features --> Local APIC support on uniprocessors --> IO-APIC support on uniprocessors. Both of the last 2 options have to be turned on.

Or, you can use an SMP kernel (with an SMP motherboard, and it probably needs to be outfitted with 2 actual processors also); that will enable IO-APIC support automatically (it's required to allow the processors to cooperate regarding interrupts).

Then, make sure you DON'T boot with the "noapic" option -- or make sure you DO boot with the "apic" option. That will enable the IO-APIC code which allows 32 IRQs.

To check while the kernel is running, do a cat /proc/interrupts -- if all of them are listed as XT-PIC, then IO-APIC support is not enabled. If most are either IO-APIC-edge or IO-APIC-level (the difference is, -level can be shared, -edge has to be given to only one device at a time), then you're using the IO-APIC support, and you should have a whole lot more IRQs.

There will be a couple IRQs listed as XT-PIC either way, but not many.

[root.veg]

sorted out the kernel stuff - got a stock Debian 2.6.6 kernel for the moment until I can bother to read the instructions properly...

apt-get installed module-init-utils automatically, allowing me to successfully download and compile the latest NVidia driver.

Can't find any direct reference to APIC in the 2.6 kernel configuration, except there's one option for Vector-based interrupt indexing (MSI) which mentions support for IOxAPIC in the help notes. I'll try it when I re-compile my kernel again.

[bwkaz]

Originally posted by root.veg
Can't find any direct reference to APIC in the 2.6 kernel configuration, except there's one option for Vector-based interrupt indexing (MSI) which mentions support for IOxAPIC in the help notes. That's not it.

Did you see where I posted exactly where the option is? I'll do it again. Under {menu,x,g}config (and the plain-config option names are also given this time):

Processor type and features --> Local APIC support on uniprocessors (CONFIG_X86_UP_APIC) --> IO-APIC support on uniprocessors (CONFIG_X86_UP_IOAPIC)

Both the last 2 options have to be turned on.

They go away if you enable SMP, or if you aren't configuring for an x86 architecture, but that's the only time they aren't there.

[root.veg]

Got 'em... I had SMP enabled for some reason, hence I couldn't find the two options initially.

Compiling as I write... if you don't here from me it's because it works:)

[root.veg]

Stuck with the stock 2.6.6 Debian kernel for now, as I wanted to find out more before installing my own.

However... when I now plug my sound card in, it now WORKS! I have no idea what I did to make this happen... cat /proc/interrupts gives the following:

CPU0
0: 2360437 XT-PIC timer
1: 4699 XT-PIC i8042
2: 0 XT-PIC cascade
5: 80179 XT-PIC ohci_hcd, eth0
7: 2 XT-PIC parport0
8: 4 XT-PIC rtc
9: 289 XT-PIC uhci_hcd, ehci_hcd
10: 66 XT-PIC ohci_hcd
11: 205149 XT-PIC EMU10K1, nvidia
12: 152974 XT-PIC i8042
14: 17925 XT-PIC ide0
15: 408824 XT-PIC ide1
NMI: 0
LOC: 2360636
ERR: 0
MIS: 0

Meaning my sound card and graphics card are both sharing IRQ 11, but working (apparently) OK now: tested OK in normal unaccelerated X session and using Quake3 and UT.

So...

1) any ideas how this is possible? (I thought IRQ sharing was a Bad Thing)

2) is it somehow "dangerous" to keep running with the two cards sharing the same IRQ?

:confused:

[bwkaz]

Originally posted by root.veg
1) any ideas how this is possible? (I thought IRQ sharing was a Bad Thing) It's only a Bad Thing if any of the cards in question don't support IRQ sharing.

It's not necessarily always bad -- I have nvidia and YMFPCI (my sound card driver) sharing IO-APIC-level IRQ 16, and I have bttv0 and "Bt87x audio" sharing IO-APIC-level IRQ 18. Also my USB 1.1 and USB 2.0 controllers all share IO-APIC-level IRQ 21. And everything works fine.

It depends on your hardware and the drivers, mostly.

However, the "level" part of IO-APIC-level is required. If the IRQ that's being shared is edge-triggered rather than level-triggered, then the sharing will never work properly. The reason is that while the CPU is servicing one IRQ, it masks interrupts. If another comes in at that point, it will be lost (since only the rising or falling edge of the signal going into the interrupt controller triggers an interrupt, and interrupts are currently blocked).

However, if the IRQ that's being shared is level-triggered, then the signal being low (or high) is what triggers the interrupt. If the CPU is servicing one interrupt and another one happens, the interrupt controller won't see it right away, but it doesn't matter. When the CPU finishes servicing the first, it will clear the card that generated the interrupt, which will allow the IRQ line to come back to a "normal" state. But the second card will still be holding the signal low (or high), so the interrupt controller will immediately generate another interrupt, and eventually the CPU will handle all of them that get generated.

Now, there is a small latency introduced with interrupt sharing if the first interrupt takes a significant amount of time to service. Which is why sharing them is sometimes bad -- but it doesn't affect correctness usually. If it's working properly, that is.

And with XT-PIC interrupts, I don't know what decides whether they're level-sensitive or edge-triggered. Maybe that was the problem? The IRQ in question was edge-triggered before, but is level-sensitive now?

2) is it somehow "dangerous" to keep running with the two cards sharing the same IRQ? Not if it's working. :)