CUSL2C BIOS help please?

  • Thread starter Thread starter Hugh Jass
  • Start date Start date
H

Hugh Jass

Hello,

I am using my CUSL2-C trying to use a card that requires PCI 2.2. The
documentation claims the CUSL2 is 2.2 compatible in all slots. Yet I can't
get the card to be recognized. This is a special telephony interface card
from Digium so I doubt that many here have it.

My question is, were there any changes in the BIOS that would affect this
PCI 2.2 compatibility?

I'd really appreciate help or pointers on this, I can't seem to find much
doc on what the various BIOS versions brought to the mix. I saw the last
official seemed to be 1009 and there was a 1014 "beta" in 2002?

tia
 
Hugh said:
Hello,

I am using my CUSL2-C trying to use a card that requires PCI 2.2. The
documentation claims the CUSL2 is 2.2 compatible in all slots. Yet I can't
get the card to be recognized. This is a special telephony interface card
from Digium so I doubt that many here have it.

My question is, were there any changes in the BIOS that would affect this
PCI 2.2 compatibility?

I'd really appreciate help or pointers on this, I can't seem to find much
doc on what the various BIOS versions brought to the mix. I saw the last
official seemed to be 1009 and there was a 1014 "beta" in 2002?

tia
Click to expand...

This seems like a multi-device PCI card with a PCI-to-PCI bridge chip
onboard (i.e. the actual devices reside on a separate PCI bus which is
implemented on the card itself). It is way more likely that the
motherboard's BIOS does a shitty job at detecting/initialising PCI
devices behind a PCI-to-PCI bridge, i.e. the only PCI buses the
motherboard's BIOS is (and can be) aware of are the two standard PCI
buses the motherboard has (the PCI bus on which the PCI slots reside and
the crippled PCI bus on which the AGP slot resides).
I really doubt PCI 2.2 compliance has anything to do with the improper
detection of the card. I can't rule it out, and of course I don't really
know if this card does indeed have a PCI-to-PCI bridge. But the CUSL2
series IS PCI 2.2 compliant anyway so you get the idea. PCI 2.2 has to
do with standby power on the slots and wake-up capabilities (this card
is a telephony card so wake-up capabilities are a logical thing to
implement, thus PCI 2.2 compliance is essential but ONLY for the wake-up
capabilities).
After all... these are the hardware requirements for the card direct
from its site:
* Hardware and Software Requirements
* 500 Mhz Pentium III of better with 64MB RAM
* Available PCI Slot
* Linux 2.4 Kernel

Nowhere is PCI 2.2 compliance mentioned as a *requirement* - the only
implied thing is that IF you have a PCI 2.2 compliant system the card
can take advantage of it since it's PCI 2.2 compliant as well.

Regards
Nikos
 
On Sat, 03 Apr 2004 22:22:35 +0300, Nikolaos Tampakis wrote:

Thanks for replying, Nikos

One thing though, PCI 2.2 IS required, it's written in red and I wasn't
sure either by the wording (it says the *card* is PCP 2.2 compliant), but
Digium says it is. I tried the card on a different board, the P4C800 and
it doesn't appear to be detected there either. I say appear because I used
a Trinux diskette and did a hardware list of PCI devices connected.
Unfortunately since I bought direct from them and I am in Europe, it will
be costly to send it back.
 
Hugh said:
On Sat, 03 Apr 2004 22:22:35 +0300, Nikolaos Tampakis wrote:

Thanks for replying, Nikos

One thing though, PCI 2.2 IS required, it's written in red and I wasn't
sure either by the wording (it says the *card* is PCP 2.2 compliant), but
Digium says it is. I tried the card on a different board, the P4C800 and
it doesn't appear to be detected there either. I say appear because I used
a Trinux diskette and did a hardware list of PCI devices connected.
Unfortunately since I bought direct from them and I am in Europe, it will
be costly to send it back.
Click to expand...

I maintain that PCI 2.2 compliance of the motherboard isn't essential
for the board to be recognised, at least it shouldn't be essential. But
anyway, since both boards you tried it on ARE PCI 2.2 compliant, PCI 2.2
compliance or not is not the problem.
I'm beginning to think you actually have a dead card... even if the card
does use a PCI-to-PCI bridge (you can ask Digium about that), I'd find
it hard to believe that two Asus boards' BIOS would fail to scan beyond
a bridge.

Regards
Nikos
 
I maintain that PCI 2.2 compliance of the motherboard isn't essential
for the board to be recognised, at least it shouldn't be essential. But
anyway, since both boards you tried it on ARE PCI 2.2 compliant, PCI 2.2
compliance or not is not the problem.
Click to expand...
I'm beginning to think you actually have a dead card... even if the card
does use a PCI-to-PCI bridge (you can ask Digium about that), I'd find
it hard to believe that two Asus boards' BIOS would fail to scan beyond
a bridge.
Click to expand...

Ok here's the mystery: The board works now by loading the proper modules
in linux. Since I'm a relative unix newbie, I did not realize that
"modprobe" had to be issued. As far as I can see, the *BIOS* does not see
the card in it's initial boot screen list - why isn't there an option to
hold that IRQ listing so I could be sure?

I have tried everything I can think of to take control of the IRQ
assignments. Well, everything except reserving three IRQ for non ISA like
boards. Whatever I have tried, the IRQ do NOT seem to be assigned in ay
order resembling the slot order.

Long story short, these three are all intense interrupt users and should
each be on its own IRQ. I even removed the sound card so there is just the
NIC and my three Digium cards.

Right now everything is actually working right.
 
Hugh said:
Ok here's the mystery: The board works now by loading the proper modules
in linux. Since I'm a relative unix newbie, I did not realize that
"modprobe" had to be issued. As far as I can see, the *BIOS* does not see
the card in it's initial boot screen list - why isn't there an option to
hold that IRQ listing so I could be sure?
Click to expand...

Good you worked it out :) you can actually press the PAUSE key right
when that screen appears and take a closer look.
I have tried everything I can think of to take control of the IRQ
assignments. Well, everything except reserving three IRQ for non ISA like
boards. Whatever I have tried, the IRQ do NOT seem to be assigned in ay
order resembling the slot order.
Click to expand...

AFAIK the CUSL2 BIOS does support working manual IRQ assignment - I used
to have a CUSL2 in a test lab since Sep. 2000 and can't say it ever gave
me any trouble.
Note however than the OS may change the BIOS' initial IRQ assignments.
On the screen with the PCI devices listing though, the IRQs displayed
ought to match the ones specified per-slot in the BIOS.
Long story short, these three are all intense interrupt users and should
each be on its own IRQ. I even removed the sound card so there is just the
NIC and my three Digium cards.

Right now everything is actually working right.
Click to expand...

Way to go!

Regards
Nikos
 
Nikos,

Thank you again for your very useful comments. I'll have to try the pause
key, I've been playing with this stuff since 1983 and I guess I never got
it timed right! In the old 386 days, the list was up there for a few
seconds.
 
AFAIK the CUSL2 BIOS does support working manual IRQ assignment - I used
to have a CUSL2 in a test lab since Sep. 2000 and can't say it ever gave
me any trouble.
Note however than the OS may change the BIOS' initial IRQ assignments.
On the screen with the PCI devices listing though, the IRQs displayed
ought to match the ones specified per-slot in the BIOS.
Click to expand...

As a final note, I had a little troublme with the IRQs being shared and
had to play musical chairs again with the cards and slots.

I finally realized that slots 1 and 5 share an IRQ, so it was easy to not
put anything in slot 5. I had already disabled USB and serial and parallel
ports as I do not need any of these.

When I changed the boards to 1,2, 4 and 6, everything works smoothly (for
now!) and all the comm cards are on their own IRQ as is the NIC. Cross
fingers!
 
Back
Top