PCI Parport Karte streikt nach BIOS Update

[Jan Seiffert]

Am 24. Januar 2011 21:32 schrieb Stefan U. Hegner <stefan at hegner-online.de>:
> Moin Jan,
>
> ... na, willst Du mal wieder mein "weisser Ritter des Parports" sein ?  ;-))
>

Nein, heute habe ich meine PCI-Ruestung an und die BIOS Hasskappe...

> Jan Seiffert schrieb:
[snip]
>> Ich denke das BIOS-Update hat den Code kaputt gemacht der "nicht
>> onboard" legacy Schnittstellen dahin mappt wo man sie normalerweise
>> erwartet. Oder sie werden nicht mehr ins PnP/ACPI eingetragen. Oder
>> dass das legacy decode flag wird nicht angemacht wenn legacy
>> schnittstellen eingesteckt werden.
>>
> ... whatever. Intersessant ist, dass vor dem BIOS-Update die Ports auf
> 0x5040, 0x5050 waren und jetzt 0x3040, 0x3050 gezogen wird.
>

Hmmm,  auf 0x5000 liegt jetzt deine NW-Karte

[snip]
> $lspci --vvx
>
>    03:03.0 Bridge: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
>            Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel
>    adaptor)
>            Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
>    ParErr- Stepping- SERR+ FastB2B- DisINTx-
>            Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>    >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
>            Interrupt: pin A routed to IRQ 52
>            Region 0: I/O ports at 3050 [size=8]
>            Region 1: I/O ports at 3048 [size=8]
>            Region 2: I/O ports at 3040 [size=8]
>            Region 3: I/O ports at 3038 [size=8]
>            Region 4: I/O ports at 3030 [size=8]
>            Region 5: I/O ports at 3020 [size=16]
>            Kernel modules: parport_pc
>    00: 10 97
Netmos
> 15 98
9815
>  03 01
command
> 80 82
Status
> 01
Revision
> 00 80 06
Class Code. WTF? Da sollte laut Datenblatt 070102 drinn sein. Hat da
der Hersteller das EEProm vergurgt?
Das ist grad ein "Bridge device, other" und nicht "Simple
Communications Controllers, ECP 1.x". Dann koennte ja auch der
generische Windows Treiber gehen...

Rest passt so.
Der Kernel geht ja auf die Vendor/device ID los, aber der richtige
ClassCode wuerde dem BIOS helfen...

[   17.029774] parport_pc 0000:03:03.0: PCI INT A -> GSI 52 (level,
low) -> IRQ 52
[   17.053950] PCI parallel port detected: 9710:9815, I/O at
0x3050(0x3048), IRQ 52
[   17.053975] PCI parallel port detected: 9710:9815, I/O at
0x3040(0x3038), IRQ 52

Das sind die beiden Print die ich meinte. parport_pc, der PCI part
fuehlt sich zustaendig, probed die beiden Ports: Nur danach kommt nix
mehr.
Das Probing bricht ab, da es wohl auch nur Muell liest wenn es mal
wirklich das Device anfasst.
Wenn du die Portaddressen forced (in der /etc/modprobe da was auch
immer) dann gibt er nicht auf, aber wenn da nix kommt kommt da nix. Du
kannst mit forcing das ding eben ins "nichts" legen, das ist fuer
gaaaanz alte ports gedacht wo man eben wissen muss wo die sind.

> Komplette Dateien kommen separat als PM.
>
[snip - Stefan setzt den IRQ hart auf 7 & 5]
>> Dein IRQ saugt...
>>
> ... was auch immer Du damit sagen willst ...

Das Ding steht auf 52 (was ein "nicht PIC" (ISA) Interrupt ist). Man
kann die PCI Interrupte ueber den PIC leiten, um legacy Kompatibel zu
sein, das muss aber aufgesetzt werden. Nur weil es ein Parport ist,
ist es nicht automatisch, ja _autoMAGISCH_, auf 7 & 5. It's PCI, baby!
Nich ISA mit "wir haben-koennen-wollen-nix".

Ausser der Classcode waere richtig, dann haette das BIOS das
vielleicht so hingelegt das es an Stelle der Legacy Schnittstellen
liegt.

[snip - keine device nodes]
>>> irritiert mich die dmesg Ausgabe:
>>>
>>>    parport 0x3050 (WARNING): CTR: wrote 0x0c, read 0xff
>>>    parport 0x3050 (WARNING): DATA: wrote 0xaa, read 0xff
>>>    parport 0x3050: You gave this address, but there is probably no
>>>    parallel port there!
>>>    parport0: PC-style at 0x3050, irq 7 [PCSPP,TRISTATE]
>>>    lp0: using parport0 (interrupt-driven).
>>>    parport 0x3040 (WARNING): CTR: wrote 0x0c, read 0xff
>>>    parport 0x3040 (WARNING): DATA: wrote 0xaa, read 0xff
>>>    parport 0x3040: You gave this address, but there is probably no
>>>    parallel port there!
>>>    parport1: PC-style at 0x3040, irq 0 [PCSPP,TRISTATE]
>>>    parport1: irq 0 in use, resorting to polled operation
>>>    lp1: using parport1 (polling).
>>>
>>> Warum findet er an der Adresse keinen Parallelport?
>>>

Weil da offenbar nix antwortet.
0xff ist normalerweise offenes Bus-Ende.

>>
>> Weil entweder der Chip luegt und er das nicht kann

Ich korrigiere mich, der Chip kann das, lag ja vorher auch auf 0x5000

>> oder weil der Bus nicht richtig eingestellt ist.

Was ich mittlerweile eher vermute.
Und es kann sein dass das BIOS da nichts fuer kann, es hat beim init
die recource einfach woanders hingelegt (ist frei das so zu tun, is ja
schliesslich PnP).

Ich tippe mittlerweile eher das sich Linux beim PCI setup verhaspelt.
Wobei das lustige ist, das deine FritzCard geht... hmmm.

<Monolog>
Linux hat die "unangenehme" eigenschaft beim boot das PCI setup
nochmal selber zu machen, hauptsaechlich das alle Bus-Rescourcen neu
alloziert werden. Etwas was Windows nicht macht, es nimmts wie vom
BIOS vorgefunden.
Da das Problem aber non-trivial ist macht Linux dabei schon mal Fehler
(oder einfach etwas womit die HW so nicht rechnet, oder bzw muss sich
dabei auf Firmwareinfo verlassen die nicht Stimmt, den Windows
ignoriert sie...).

Naja, OK, BIOS verkacken auch schon mal. "Frueher"TM muss es wohl sehr
schlimm gewesen sein, warum Linux das ueberhaupt alles selber macht.
Mittlerweile "verkacken" sie schon mal wieder haeufiger, da nun
Windows mittlerweile wenn die richtigen ACPI Methoden vorhanden sind
auch nachkonfiguriert (CRS). Deshalb ist dann die Base konfig grade so
lauffaehig, alles andere ist dann in ACPI Tabellen versenkt. Aber wie
gut die sind, mit welchem OS die getested sind und wie gut Linux mit
ACPI klar kommt, das wissen wir ja...

Linux nutzt CRS nicht.
Das selbst durch konfen verdeckt viele situationen in denen CRS
notwendig waere, aber so richtig alles richtig hinbekommen tut Linux
ohne CRS leider nicht immer, da in diesen Tabellen beschraenkungen
codifiziert sind, von denen Linux nichts wissen kann (besonders
schlimm z.B.: Notebooks. Das GraKa BIOS liegt oft mit im HauptBIOS und
wird von diesem beim starten nur ins System RAM kopiert. Linux sollte
also tunlichst vermeiden das GraKa BIOS zu reallozieren (also an eine
andere Adresse zu legen da es dann "besser" ins mapping passt), denn
an der neuen Stelle im RAM ist nichts).
Der Grund warum CRS nicht benutzt wird ist malwieder "ueblich": Einige
Systeme haben kaputte CRS Tabellen, wenn Linux sie nimmt geht nix
mehr. Andere Systeme kommen ohne CRS nicht hoch (oder z.B. nur noch
VGA geht, der GraKa Treiber tut nicht). Lange hat Linux CRS nicht mal
unterstuezt, mittlerweile tut es das, aber es ist std. maessig aus.
Sie versuchen glaube ich jetzt schon seit 3 Kernel Version Patches zu
mergen die es std. an machen, kurz vor relaese werden sie meist wieder
rausgeschmissen da es regressions gibt...

Darum gruesst einen seit einiger Zeit folger Text im dmesg:
PCI: Ignoring host bridge windows from ACPI; if necessary, use
"pci=use_crs" and report a bug

Nagut, nicht bei dir, dein Debian ist mal wieder zu alt...
</Monolog>

hmmm
aber eigentlich ist alles richtig eingestellt:
00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port
[    0.641047] pci 0000:00:01.0: bridge io port: [0x2000-0x3fff]
01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge B (rev 09) (prog-if 00 [Normal decode])
[    0.641346] pci 0000:01:00.2: bridge io port: [0x3000-0x3fff]

und da liegen dann ja deine FritzCard und die Parport Karte.
Und die Fritz geht ja:
[   17.254316] fcpci 0000:03:01.0: PCI INT A -> GSI 48 (level, low) -> IRQ 48
[   17.277721] fcpci: AVM FRITZ!Card PCI found: port 0x3000, irq 48

Wenn du es grad aus irgendeinem Repo instllieren/compilieren kannst
(oder Live CD FTW, nur booten, dmesg & lspci extrahieren), probier mal
einen neueren Kernel, irgendwas >= 2.6.35. Vielleicht auch mit
"pci=use_crs".
Ansonsten laufe ganz schnell nach /var/log/ und suche schnell ein
dmesg von vor dem BIOS update, bevor es weggeraeumt wird.

Anderen PCI-Steckplatz ausprobieren, da sind ja mehrere PCI-Bridges.
Aber das Board wird ja nicht soviele Steckplaetze haben, hmmm.
Den Steckplatz der Fritz probieren. Die vielleicht mal testweise weglassen.
Hat einer so einen PCIe-PCI Adapter-Riser zum testen (sowas halt:
http://www.amazon.com/Startech-PCI-Express-Adapter-Card/dp/B0024CV3SA)?

Was die Frage aufwirft obs unter $OTHER_OS geht...

[snip]
> Gruß
>
> Stefan.
>
>

Gruss
Jan


-- 
Murphy's Law of Combat
Rule #3: "Never forget that your weapon was manufactured by the
lowest bidder"