Hi kernel hackers,
I have a problem with a GPIB PCI card from Quancom
( http://quancom.de/qprod01/eng/pb/pci_gpib.htm ).
I wrote a programm to read data <100kByte/sec from the GPIB bus to the RAM.
When the PCI card shares it's IRQ it works for some time and then hardlocks
my computer - the "PCI access LED" of the GPIB card is always ON then.
Now I found a PCI slot where the card doesn't have to share the IRQ - but
linux ignores the card :-(
While booting the kernel says:
---
<6>PCI: Probing PCI hardware
<4>PCI: ACPI tables contain no PCI IRQ routing entries
<4>PCI: Probing PCI hardware (bus 00)
<3>PCI: device 00:09.0 has unknown header type 04, ignoring.
<6>PCI: Using IRQ router VIA [1106/3074] at 00:11.0
---
The BIOS bootscreen reported an "unknown device - IRQ5". But "lspci" doesn't
show up the card!!!
What is "unknown header type 04" ?
Why does "lspci" show the card when IRQ is shared?
How can I know what's wrong with this card?
Somebody please enlighten me.
Please CC me your mail - I'm not subscribed to the list.
Greetings
Michael
PS: I already had trouble with this card spontaneously getting unconfigured
(like before the BIOS talks to the card) in an ECS L7S7A board ...
My system:
Athlon 2000XP
512MB RAM
Epox 8KHA+ (VIA KT266a)
Suse8.2
2.4.22 kernel
3.1.97 linux gpib driver
Followup to: <[email protected]>
By author: Michael Born <[email protected]>
In newsgroup: linux.dev.kernel
>
> What is "unknown header type 04" ?
> How can I know what's wrong with this card?
>
There is no header type 4 (type 0 and 1 exist, but not 4.) That means
your card is not compliant with the PCI specification, and any attempt
at accessing this device is based on guesswork.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
On Thu, 13 Nov 2003, Michael Born wrote:
> Hi kernel hackers,
>
> I have a problem with a GPIB PCI card from Quancom
> ( http://quancom.de/qprod01/eng/pb/pci_gpib.htm ).
>
You probably need to talk to them.
> I wrote a programm to read data <100kByte/sec from the GPIB bus to the RAM.
> When the PCI card shares it's IRQ it works for some time and then hardlocks
> my computer - the "PCI access LED" of the GPIB card is always ON then.
The PCI specification requires that all devices be able to share
an interrupt. If the provided driver won't allow this, then it is
broken. You need to contact the vendor.
Also, since the GPIB specification requires that a machine be addressed
to talk before it can talk, etc., you can see that hangs are possible
unless the driver is carefully designed to time-out if the talker doesn't
talk or the listener doesn't listen. Even if you have good hardware,
real-world use may require you to write your own driver. For instance,
a data-transfer is happening between a device and your PC. Somebody
turns off the device. You don't want to have to re-boot. Many
hardware vendors don't have a clue about real-world applications when
they make a so-called "driver". You use they code as an example
of how to talk to their board. You make the real driver yourself.
> Now I found a PCI slot where the card doesn't have to share the IRQ - but
> linux ignores the card :-(
> While booting the kernel says:
> ---
> <6>PCI: Probing PCI hardware
> <4>PCI: ACPI tables contain no PCI IRQ routing entries
> <4>PCI: Probing PCI hardware (bus 00)
> <3>PCI: device 00:09.0 has unknown header type 04, ignoring.
> <6>PCI: Using IRQ router VIA [1106/3074] at 00:11.0
>
We don't know if 00:09.0 is your board, but a header type 04
is currently not defined. There are three header types, 0->2.
Type one is for PCI-PCI bridges.
Type two is for PCI-Cardbus bridges.
All others are type zero. The specification says ALL others
are type zero, not "some of the others".
---
>
> The BIOS bootscreen reported an "unknown device - IRQ5". But "lspci" doesn't
> show up the card!!!
>
lspci will only show a configured controller. Normally the BIOS will
configure it. Eventually the kernel may re-configure it. However,
with an incorrect header, this won't happen. The board vendor
may have "worked-around" this problem with his driver by forcing
bits into configuration registers to make it "function". This
has a fatal flaw in that a module (driver) doesn't have enough
information available to successfully allocate I/O space on its
own.
> What is "unknown header type 04" ?
> Why does "lspci" show the card when IRQ is shared?
> How can I know what's wrong with this card?
>
See above. Return board. Look on Web-sites for others, Hint; National
Instruments. They work.
> Somebody please enlighten me.
> Please CC me your mail - I'm not subscribed to the list.
>
> Greetings
> Michael
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, 13 Nov 2003, Richard B. Johnson wrote:
>> While booting the kernel says:
>> ---
>> <6>PCI: Probing PCI hardware
>> <4>PCI: ACPI tables contain no PCI IRQ routing entries
>> <4>PCI: Probing PCI hardware (bus 00)
>> <3>PCI: device 00:09.0 has unknown header type 04, ignoring.
>> <6>PCI: Using IRQ router VIA [1106/3074] at 00:11.0
>
>We don't know if 00:09.0 is your board, but a header type 04
>is currently not defined. There are three header types, 0->2.
...
>> The BIOS bootscreen reported an "unknown device - IRQ5". But "lspci" doesn't
>> show up the card!!!
>
>lspci will only show a configured controller. Normally the BIOS will
>configure it. Eventually the kernel may re-configure it. However,
>with an incorrect header, this won't happen. The board vendor
>may have "worked-around" this problem with his driver by forcing
>bits into configuration registers to make it "function". This
>has a fatal flaw in that a module (driver) doesn't have enough
>information available to successfully allocate I/O space on its
>own.
There could be a few other things going on here... like a broken BIOS. And
it could simply be problems reading the PCI configuration space for that
board. Check the BIOS settings for the PCI bus. Try the card in different
machine(s) -- made by different manufacturers with different BIOSes.
(FWIW, I have a machine that doesn't like certain PCI cards, and certainly
doesn't like multiple ones -- it assigns them all the *same* memory
sections.)
I've been seeing the same messages on sparc hardware (UltraAXi, Netra T1,
U5, etc.) for, oh, a year:
PROMLIB: Sun IEEE Boot Prom 4.0.3 2001/01/03 15:05
Linux version [email protected] (root@spacemeat) (gcc version 3.2.3) #14 BK(
03/10/22-13:42:11-04:00) Wed Oct 22 14:33:57 EDT 2003
ARCH: SUN4U
...
PCI: Probing for controllers.
PCI: Found SABRE, main regs at 000001fe00000000, wsync at 000001fe00001c20
SABRE: Shared PCI config space at 000001fe01000000
SABRE: DVMA at c0000000 [20000000]
PCI: device 0000:00:01.3 has unknown header type 10, ignoring.
PCI: device 0000:00:01.4 has unknown header type 10, ignoring.
PCI: device 0000:00:01.5 has unknown header type 10, ignoring.
PCI: device 0000:00:01.6 has unknown header type 10, ignoring.
PCI: device 0000:00:01.7 has unknown header type 10, ignoring.
PCI: device 0000:00:02.0 has unknown header type 10, ignoring.
...
PCI: device 0000:00:1e.0 has unknown header type 10, ignoring.
PCI: device 0000:00:1f.0 has unknown header type 10, ignoring.
(it's not always 10, btw.)
I'm guessing it's because the configuration space isn't being zero'd or
something like that. In this case, it's only complaining about things
that aren't actually there.
--Ricky
On Thu, 13 Nov 2003, Ricky Beam wrote:
> On Thu, 13 Nov 2003, Richard B. Johnson wrote:
> >> While booting the kernel says:
> >> ---
> >> <6>PCI: Probing PCI hardware
> >> <4>PCI: ACPI tables contain no PCI IRQ routing entries
> >> <4>PCI: Probing PCI hardware (bus 00)
> >> <3>PCI: device 00:09.0 has unknown header type 04, ignoring.
> >> <6>PCI: Using IRQ router VIA [1106/3074] at 00:11.0
> >
> >We don't know if 00:09.0 is your board, but a header type 04
> >is currently not defined. There are three header types, 0->2.
> ...
> >> The BIOS bootscreen reported an "unknown device - IRQ5". But "lspci" doesn't
> >> show up the card!!!
> >
> >lspci will only show a configured controller. Normally the BIOS will
> >configure it. Eventually the kernel may re-configure it. However,
> >with an incorrect header, this won't happen. The board vendor
> >may have "worked-around" this problem with his driver by forcing
> >bits into configuration registers to make it "function". This
> >has a fatal flaw in that a module (driver) doesn't have enough
> >information available to successfully allocate I/O space on its
> >own.
>
> There could be a few other things going on here... like a broken BIOS. And
> it could simply be problems reading the PCI configuration space for that
> board. Check the BIOS settings for the PCI bus. Try the card in different
> machine(s) -- made by different manufacturers with different BIOSes.
> (FWIW, I have a machine that doesn't like certain PCI cards, and certainly
> doesn't like multiple ones -- it assigns them all the *same* memory
> sections.)
>
> I've been seeing the same messages on sparc hardware (UltraAXi, Netra T1,
> U5, etc.) for, oh, a year:
>
> PROMLIB: Sun IEEE Boot Prom 4.0.3 2001/01/03 15:05
> Linux version [email protected] (root@spacemeat) (gcc version 3.2.3) #14 BK(
> 03/10/22-13:42:11-04:00) Wed Oct 22 14:33:57 EDT 2003
> ARCH: SUN4U
> ...
> PCI: Probing for controllers.
> PCI: Found SABRE, main regs at 000001fe00000000, wsync at 000001fe00001c20
> SABRE: Shared PCI config space at 000001fe01000000
> SABRE: DVMA at c0000000 [20000000]
> PCI: device 0000:00:01.3 has unknown header type 10, ignoring.
> PCI: device 0000:00:01.4 has unknown header type 10, ignoring.
> PCI: device 0000:00:01.5 has unknown header type 10, ignoring.
> PCI: device 0000:00:01.6 has unknown header type 10, ignoring.
> PCI: device 0000:00:01.7 has unknown header type 10, ignoring.
> PCI: device 0000:00:02.0 has unknown header type 10, ignoring.
> ...
> PCI: device 0000:00:1e.0 has unknown header type 10, ignoring.
> PCI: device 0000:00:1f.0 has unknown header type 10, ignoring.
>
> (it's not always 10, btw.)
>
> I'm guessing it's because the configuration space isn't being zero'd or
> something like that. In this case, it's only complaining about things
> that aren't actually there.
>
> --Ricky
>
Well if the configuration space isn't "zeroed" as you say, then
the hardware is broken --plain-and-simple. This register is
mandatory. It must contain bits that relate to the device.
The bits are set/reset by hardware. If there are any "floating"
bits, then the CPU is not able to correctly read a DWORD (unlikely
if you booted).
There is a serious problem with a lot of junk hardware. Instead
of fixing the board, the vendor calls M$ or the BIOS vendor and
requests a work-around. Since open-source software doesn't get
these free fixes, the vendors get to blame Linux. Just don't
use that crap. Plain and simple. If it's broken, don't fix it
in sofware. Most everybody knows that since there are only
three possible (currently) header types, a simple AND will
"fix" the board during configuration. However, how many other
failures to meet specifications are in that PCI/Bus board?
You don't know. However, you got a hint. If the board fails
to handle the bus properly, you corrupt your hard disk, you
lose all your work, etc.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Thanks a lot for your responses. I did some more testing and have one more
question.
In the "nonshared IRQ" PCI slot 0.9.0 the card works with the Quancom driver
under Win2k but is ignored by linux 2.4.22 - as I wrote before.
In "shared IRQ" PCI slot 0.c.0 the card is recognized by linux - lspci:
00:0c.0 Class ff00: Quancom Electronic GmbH: Unknown device 3302 (rev 11)
The driver I use is open source ( see: http://linux-gpib.sourceforge.net/ ).
The maintainer helped me a lot to get this Ines-GPIB clone card running.
Is there a board / vendor who has good BIOS and PCI implementations?
If I understand correctly - there is no simple way to tell a good PCI card
apart from a bad one ? If I would send back the card they would want to know
what exactly the problem ist - but when nobody knows that ???
Greetings
Michael
Am Donnerstag, 13. November 2003 21:57 schrieb Ricky Beam:
> On Thu, 13 Nov 2003, Richard B. Johnson wrote:
> >> While booting the kernel says:
> >> ---
> >> <6>PCI: Probing PCI hardware
> >> <4>PCI: ACPI tables contain no PCI IRQ routing entries
> >> <4>PCI: Probing PCI hardware (bus 00)
> >> <3>PCI: device 00:09.0 has unknown header type 04, ignoring.
> >> <6>PCI: Using IRQ router VIA [1106/3074] at 00:11.0
> >
> >We don't know if 00:09.0 is your board, but a header type 04
> >is currently not defined. There are three header types, 0->2.