Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#8511 - [fcpci] Try to load Firmware on a FritzCard

Attached to Project: Arch Linux
Opened by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 10:59 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 23 November 2007, 11:57 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas B├Ąchler (brain0)
Roman Kyrylych (Romashka)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
After Kernel-Update to 2.6.23 and with depend AVM-Modul update
/etc/rc.d/capiinit failed.
Trying to start it by hand, capiinit says:
[root@s02 ~]# capiinit activate
ERROR: controller 1: firmware file "-" not found
ERROR: failed to load firmware for controller 1 driver fcpci name fcpci-d400-20

Seems capiinit means - in /etc/capi.conf is a firmware file, not a
parameter for: no firmware needed.

Additional info:
* package version(s)
kernel26 2.6.23.1-6
extra/fcpci 31107-33

Temporary solution for me is: go back to kernel 2.6.22 an fcpci 31107-31

This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 23 November 2007, 11:57 GMT
Reason for closing:  Fixed
Comment by Tobias Powalowski (tpowa) - Monday, 05 November 2007, 17:34 GMT
fcpci: AVM FRITZ!Card PCI driver, revision 0.7.2
fcpci: (fcpci built on Oct 11 2007 at 06:46:53)
fcpci: -- 32 bit CAPI driver --
PCI: Enabling device 0000:00:0f.0 (0100 -> 0103)
ACPI: PCI Interrupt 0000:00:0f.0[A] -> GSI 18 (level, low) -> IRQ 18
fcpci: AVM FRITZ!Card PCI found: port 0xb400, irq 18
fcpci: Loading...
fcpci: Driver 'fcpci' attached to fcpci-stack. (152)
fcpci: Stack version 3.11-07
kcapi: Controller [001]: fcpci-b400-18 attached
kcapi: card [001] "fcpci-b400-18" ready.
fcpci: Loaded.

for me no issue and it works.
fcpci - - - - - -
Comment by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 18:34 GMT
First: sorry for my bad english.

I've rechecked this by reinstalling 26.23 and fcpci for this kernel.

My report with this firmware error is not relevant. I also got this error when my capi works in 2.6.22.
It seems every: capiinit reload produce this error always when the card is already active.

But my problem still exists (for which i thought i've found the reason with above firmware confusion).
Neither of my capi applications nor isdnlog and my vbox works under new kernel/fcpci.

The card/moduls load properly but i have no registered B-Channels (capiinfo)

Here some tests (first is from good(2.6.22), second is bad(2.6.23)):

------------
[root@s02 ~]# lsmod | grep -e capi -e isdn
capi 14272 0
kernelcapi 31816 2 fcpci,capi
capifs 4360 2 capi
isdn 126688 1
slhc 5760 2 ppp_generic,isdn

[root@s02 ~]# lsmod | grep -e capi -e isdn
capi 14272 0
capifs 4360 2 capi
capidrv 27540 1
kernelcapi 31944 3 capi,fcpci,capidrv
isdn 128736 6 capidrv
slhc 5760 2 ppp_generic,isdn

Here: in the bad status modul capidrv isn't loaded automatically)
-------------------------

[root@s02 ~]# capiinfo
Number of Controllers : 1
Controller 1:
Manufacturer:
CAPI Version: 2.0
Manufacturer Version: 49.23
Serial Number: 1000001
BChannels: 0
Global Options: 0x00000000
B1 protocols support: 0x00000000
B2 protocols support: 0x00000000
B3 protocols support: 0x00000000
....

[root@s02 ~]# capiinfo
Number of Controllers : 1
Controller 1:
Manufacturer: AVM GmbH
CAPI Version: 2.0
Manufacturer Version: 3.11-07 (49.23)
Serial Number: 1000001
BChannels: 2
Global Options: 0x00000039
internal controller supported
DTMF supported
Supplementary Services supported
channel allocation supported (leased lines)
B1 protocols support: 0x4000011f
64 kbit/s with HDLC framing
64 kbit/s bit-transparent operation
V.110 asynconous operation with start/stop byte framing
V.110 synconous operation with HDLC framing
T.30 modem for fax group 3
Modem asyncronous operation with start/stop byte framing
B2 protocols support: 0x00000b1b
ISO 7776 (X.75 SLP)
Transparent
LAPD with Q.921 for D channel X.25 (SAPI 16)
T.30 for fax group 3
ISO 7776 (X.75 SLP) with V.42bis compression
V.120 asyncronous mode
V.120 bit-transparent mode
B3 protocols support: 0x800000bf
Transparent
T.90NL, T.70NL, T.90
ISO 8208 (X.25 DTE-DTE)
X.25 DCE
T.30 for fax group 3
T.30 for fax group 3 with extensions
Modem
...

Yous see: In good status the bchannels and protocols are registered properly.
----------------------

[root@s02 ~]# capiinit status
1 fcpci detected fcpci-d400-21 A1 - 0xd400 0

[root@s02 ~]# capiinit status
1 fcpci running fcpci-d400-21 A1 3.11-07 0xd400 21

Here in good status the version(?) is visible and 21 at the end.
-------------------

I will recheck this another one.
Next time i update the kernel+fcpci but then i put capidrv in MODULES in rc.conf.
Maybe it's the missing module which is not autoloaded.

What says your capiinfo?
Comment by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 18:37 GMT
Sorry, mistake:

The test results from:
[root@s02 ~]# lsmod | grep -e capi -e isdn
are switched (bad copy&paste).
The first (with missing capidrv) is from BAD, the second is from GOD.

Comment by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 18:40 GMT
Oh shit, another sorry (i must drink more coffeee)

ALL tests are switched. Sorry for confusing you ;-)

FIRST output is from bad, SECOND from good.
Grrrrr.
Comment by Tobias Powalowski (tpowa) - Monday, 05 November 2007, 18:41 GMT
hrm you don't use the capiinit daemon?
Comment by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 18:45 GMT
Sure, capiinit is in rc.conf DAEMONS in both situations.

All settings are the same. I only down/upgrade kernel+fcpci
Comment by Tobias Powalowski (tpowa) - Monday, 05 November 2007, 18:48 GMT
and what do you load in rc.conf modules?
Comment by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 18:59 GMT
MODULES=(mii sis900 slhc capidrv tun)

You see, capidrv is already in MODULES.
Next minutes i try a run in 2.6.23. There i will load capidrv by hand to check for errors.
But i think the problem (bchannels) comes from fcpci.
capidrv is AFAIK only a capi "application" which register.
I need capidrv to run "old" isdnlog and vbox3 on capi.
I'am back in 10 minutes or so.
If it helps i also could login in IRC#archlinux.de for discussion?
Comment by Tobias Powalowski (tpowa) - Monday, 05 November 2007, 19:00 GMT
fine on irc
Comment by Gerhard Brauer (GerBra) - Monday, 05 November 2007, 19:16 GMT
Back on 2.6.23 (BAD)

/etc/rc.d/capiinit stop
Here is syslog when doing:
/etc/rc.d/capiinit start and modprobe capidrv

Nov 5 20:01:59 s02 CAPI Subsystem Rev 1.1.2.8
Nov 5 20:01:59 s02 capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
Nov 5 20:01:59 s02 fcpci: AVM FRITZ!Card PCI driver, revision 0.7.2
Nov 5 20:01:59 s02 fcpci: (fcpci built on Oct 11 2007 at 06:46:53)
Nov 5 20:01:59 s02 fcpci: -- 32 bit CAPI driver --
Nov 5 20:01:59 s02 fcpci: AVM FRITZ!Card PCI found: port 0xd400, irq 20
Nov 5 20:01:59 s02 fcpci: Loading...
Nov 5 20:01:59 s02 fcpci: Driver 'fcpci' attached to fcpci-stack. (152)
Nov 5 20:01:59 s02 fcpci: Stack version 3.11-07
Nov 5 20:01:59 s02 kcapi: Controller [001]: fcpci-d400-20 attached
Nov 5 20:01:59 s02 kcapi: card [001] "fcpci-d400-20" ready.
Nov 5 20:01:59 s02 fcpci: Loaded.
Nov 5 20:02:07 s02 capidrv-1: now up (0 B channels)
Nov 5 20:02:07 s02 capidrv-1: not from AVM, no d-channel trace possible ()
Nov 5 20:02:07 s02 capidrv: Rev 1.1.2.2: loaded

Comment by Tobias Powalowski (tpowa) - Tuesday, 06 November 2007, 11:23 GMT
i tried to revert all isdn changes from .23 kernel nothing changed :(
it seems a problem of capiinit or capiinfo to get the correct parameters
Comment by Gerhard Brauer (GerBra) - Tuesday, 06 November 2007, 11:55 GMT
Today i tried the kernel change in capi.c we discussed yesterday in irc.
Nothing better with these changes.

I've googled a litte but searches with "2.6.23 fcpci" and so brought nothing relevant infos.
I've recompiled also the fcpci modul.
Next i will try fcpci-Modules from OpenSuse, but these guys are still on kernel 2.6.21/22.

Perhaps i will be a little sassy and contact Karsten Keil directly ;-)
He could'nt do more than cutting my head...

Also i posted in german achlinux forum to see if someone other has a similar card, fcpci and enviroment to
recheck my problem.
Comment by Tobias Powalowski (tpowa) - Tuesday, 06 November 2007, 11:58 GMT
i try now to build a .23 kernel with .22 config perhaps it's just config releated
Comment by Gerhard Brauer (GerBra) - Tuesday, 06 November 2007, 12:31 GMT
The rpm-sources from OpenSuse have the same problem.
Modul and their patches applied/compiled fine under 2.6.23, the module loads fine as ours.
But capiinfo produce the same output without any known bchannel.
Comment by Tobias Powalowski (tpowa) - Tuesday, 06 November 2007, 12:33 GMT
config from .22 doesn't help either :/
next error source is capi4kutils or something in kernel changed that affected isdn subsystem
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 07:13 GMT
update on that:
the change was in the rc1 series of .23
now only the commit must be identified
Comment by Paolo Bernardelli (bpaolo) - Wednesday, 07 November 2007, 09:38 GMT
Probably I disturb ... but I have the same problem on fedora 7 and with the kernel 2.6.23.1-21
Linux server.intranet.conica.it 2.6.23.1-21.fc7 #1 SMP Thu Nov 1 21:09:24 EDT 2007 i686 i686 i386 GNU/Linux
I was able to have the fcpci camplied correctly

fcpci: module license 'Proprietary' taints kernel.
fcpci: AVM FRITZ!Card PCI driver, revision 0.7.2
fcpci: (fcpci built on Nov 6 2007 at 10:17:10)
fcpci: -- 32 bit CAPI driver --
ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 17 (level, low) -> IRQ 22
fcpci: AVM FRITZ!Card PCI found: port 0x9400, irq 22
fcpci: Loading...
fcpci: Driver 'fcpci' attached to fcpci-stack. (152)
fcpci: Stack version 3.11-07
kcapi: Controller [001]: fcpci-9400-22 attached
kcapi: card [001] "fcpci-9400-22" ready.
fcpci: Loaded.

and the data are correspnding to the lspci
00:09.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 02)
Subsystem: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ec800000 (32-bit, non-prefetchable) [size=32]
Region 1: I/O ports at 9400 [size=32]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=55mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

but the capiinit give a good loading of the module but is unamble
to see the Bchannel and card data.


[root@server ~]# capiinfo
Number of Controllers : 1
Controller 1:
Manufacturer:
CAPI Version: 2.0
Manufacturer Version: 49.23
Serial Number: 1000001
BChannels: 0
Global Options: 0x00000000
B1 protocols support: 0x00000000
B2 protocols support: 0x00000000
B3 protocols support: 0x00000000

0100
0000
00000000
00000000
00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000

Supplementary services support: 0x000003ff
Hold / Retrieve
Terminal Portability
ECT
3PTY
Call Forwarding
Call Deflection
MCID
CCBS

I see the capi4linux modified for 2.6.2 in march.2007.
I hope to give an help making other debug...
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 09:46 GMT
http://sidux.com/PNphpBB2-viewtopic-t-6496-start-0.html
it's also broken on debian systems.
this is just a guess but i think the error is in driver.c file of this fcpci package.
it forgets the manufacturer and the protocols it can provide, all this is defined in driver.c file
im not a coder so i cannot do here anything :/
Comment by Gerhard Brauer (GerBra) - Wednesday, 07 November 2007, 10:05 GMT
Yeah Tobias, have also seen this link (sic! from 12/06). Also some blog entries of some people.

I've posted a mail in opensuse-isdn-de, maybe Karsten could/would say something.
Any mail to AVM Linux-Support is pointless, IMHO.

I'm also not a C programmer, so i could not do something usefull.
But if you (or someone other) have a further idea, i'am willing to test it.

At the moment i could live with kernel 2.6.22, i will do sec. updates "manually" on this release.

At my point we could switch this bugreport to a waiting/researching state.
And again: for the rest of the world ;-) Thank you.
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 13:43 GMT Comment by Paolo Bernardelli (bpaolo) - Wednesday, 07 November 2007, 14:04 GMT
"i386: Move all simple string operations out of line"
De honest I don't understand.
but I have to recompile all the kernel?
Comment by Gerhard Brauer (GerBra) - Wednesday, 07 November 2007, 14:05 GMT
First thought was: am i on a false link?
Ashamed i must say i understand nearly nothing.
I interpret that: in kernel it isn't anymore possible to do someting like strcpy,strcat or 'a'+'b' or something.
Cause the compile "optimize" these away....
Hmmm....

And for our (my) problem:
Is there a chance to revert this "feature" to the old behavior?
Without to destabilize the whole kernel?
Is it possible for me to have a local patch to go around this in current an further versions of 2.6.23?
Short: could i test it with old string.c and string.h from 2.6.22?
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 14:09 GMT
we only need the header change, the rest is not important
Comment by Gerhard Brauer (GerBra) - Wednesday, 07 November 2007, 14:12 GMT
Oh, Tobias:
Tatata. If this **is** the reason then i think you realy earn a cookie for finding this commit...
Comment by Gerhard Brauer (GerBra) - Wednesday, 07 November 2007, 14:15 GMT
Ok, i try it today later.
Am i right:
I've only change code in string.h and make back those changes i find in the diff Link for string.h in this commit?
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 16:09 GMT
ok reverting the patch and recompiling the module makes it work again, with the porblem that all other binary modules breaks and need a recompile
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 16:11 GMT
ok C hackers are welcome to fix fcpci source code, i can't do it.
roman and thomas i would be really happy if you get it going again without changing the kernel.
Comment by Tobias Powalowski (tpowa) - Wednesday, 07 November 2007, 17:05 GMT
i think we will have new packages this evening, roman has already successfully hacked the i686 driver
Comment by Paolo Bernardelli (bpaolo) - Friday, 23 November 2007, 10:48 GMT
Sorry but on fedora not work
If you can suggest same tips...
(I follow your rebuild and string.h)
Even you connot help me ...
thank a lot
Comment by Tobias Powalowski (tpowa) - Friday, 23 November 2007, 10:48 GMT
our fix seems not to be complete
it works only if you replace the string.h in kernel source dir, somehow we need to tweak this
Comment by Paolo Bernardelli (bpaolo) - Friday, 23 November 2007, 11:41 GMT
Sorry but on fedora not work
If you can suggest same tips...
(I follow your rebuild and string.h)
Even you connot help me ...
thank a lot
Comment by Tobias Powalowski (tpowa) - Friday, 23 November 2007, 11:57 GMT
ok final fix goes up it works now again

Loading...