passage noyau 2.4.31-> 2.6.12 triggered-leved IRQ ?

Bonjour,
Je tente de passer ma passerelle du noyau 2.4.31 au 2.6.12, le tout
compilé sauce debian.
tout semble fonctionner normalement sauf une des 2 cartes réseaux (les
2 ont des chips rt8139)...
Dans les logs de démarrage du 2.6 j'ai :
...
Jul 28 10:39:28 hardtop kernel: 8139too Fast Ethernet driver 0.9.27
Jul 28 10:39:28 hardtop kernel: PCI: setting IRQ 11 as level-triggered
Jul 28 10:39:28 hardtop kernel: PCI: Assigned IRQ 11 for device
0000:00:08.0
Jul 28 10:39:28 hardtop kernel: eth0: RealTek RTL8139 at 0xc6800000,
00:50:fc:89:fd:a9, IRQ 11
Jul 28 10:39:28 hardtop kernel: eth0: Identified 8139 chip type
'RTL-8100B/8139D'
Jul 28 10:39:28 hardtop kernel: PCI: Found IRQ 10 for device 0000:00:09.0
Jul 28 10:39:28 hardtop kernel: eth1: RealTek RTL8139 at 0xc6802000,
00:08:54:37:90:b6, IRQ 10
Jul 28 10:39:28 hardtop kernel: eth1: Identified 8139 chip type
'RTL-8100B/8139D'
...
Jul 28 10:39:28 hardtop kernel: irq 11: nobody cared!
Jul 28 10:39:28 hardtop kernel: [<c012ec72>] __report_bad_irq+0x22/0x80
Jul 28 10:39:28 hardtop kernel: [<c012ed40>] note_interrupt+0x50/0x80
Jul 28 10:39:28 hardtop kernel: [<c012e81a>] __do_IRQ+0x11a/0x130
Jul 28 10:39:28 hardtop kernel: [<c01042ea>] do_IRQ+0x1a/0x30
Jul 28 10:39:28 hardtop kernel: [<c0102b6a>] common_interrupt+0x1a/0x20
Jul 28 10:39:28 hardtop kernel: [<c0117381>] __do_softirq+0x31/0x90
Jul 28 10:39:28 hardtop kernel: [<c0117406>] do_softirq+0x26/0x30
Jul 28 10:39:28 hardtop kernel: [<c01174c9>] irq_exit+0x39/0x40
Jul 28 10:39:28 hardtop kernel: [<c01042ef>] do_IRQ+0x1f/0x30
Jul 28 10:39:28 hardtop kernel: [<c0102b6a>] common_interrupt+0x1a/0x20
Jul 28 10:39:28 hardtop kernel: [<c012ea4e>] setup_irq+0x9e/0x120
Jul 28 10:39:28 hardtop kernel: [<c01f48d0>] rtl8139_interrupt+0x0/0x1a0
Jul 28 10:39:28 hardtop kernel: [<c012ec34>] request_irq+0x74/0x90
Jul 28 10:39:28 hardtop kernel: [<c01f38d8>] rtl8139_open+0x28/0x1b0
Jul 28 10:39:28 hardtop kernel: [<c01f48d0>] rtl8139_interrupt+0x0/0x1a0
Jul 28 10:39:28 hardtop kernel: [<c0213df8>] dev_open+0x58/0x70
Jul 28 10:39:28 hardtop kernel: [<c02151e1>] dev_change_flags+0x51/0x120
Jul 28 10:39:28 hardtop kernel: [<c02504bd>] devinet_ioctl+0x20d/0x540
Jul 28 10:39:28 hardtop kernel: [<c0252555>] inet_ioctl+0x45/0x80
Jul 28 10:39:28 hardtop kernel: [<c020b58d>] sock_ioctl+0xad/0x210
Jul 28 10:39:28 hardtop kernel: [<c015bbf7>] do_ioctl+0x57/0x70
Jul 28 10:39:28 hardtop kernel: [<c015bd83>] vfs_ioctl+0x53/0x1c0
Jul 28 10:39:28 hardtop kernel: [<c015bf1d>] sys_ioctl+0x2d/0x50
Jul 28 10:39:28 hardtop kernel: [<c01028f9>] syscall_call+0x7/0xb
Jul 28 10:39:28 hardtop kernel: handlers:
Jul 28 10:39:28 hardtop kernel: [<c01f48d0>]
(rtl8139_interrupt+0x0/0x1a0)
Jul 28 10:39:28 hardtop kernel: Disabling IRQ #11
Jul 28 10:39:28 hardtop kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1
Jul 28 10:39:28 hardtop kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 28 10:39:28 hardtop kernel: eth0: Transmit timeout, status 0c 0005
c07f media 00.
Jul 28 10:39:28 hardtop kernel: eth0: Tx queue start entry 4 dirty
entry 0.
Jul 28 10:39:28 hardtop kernel: eth0: Tx descriptor 0 is 0008a156.
(queue head)
Jul 28 10:39:28 hardtop kernel: eth0: Tx descriptor 1 is 0008a156.
Jul 28 10:39:28 hardtop kernel: eth0: Tx descriptor 2 is 0008a156.
Jul 28 10:39:28 hardtop kernel: eth0: Tx descriptor 3 is 0008a156.
Jul 28 10:39:28 hardtop kernel: eth0: link up, 100Mbps, full-duplex,
lpa 0x45E1
Jul 28 10:39:28 hardtop kernel: eth1: link up, 100Mbps, full-duplex,
lpa 0x45E1
...
A la fin du démarrage, mon eth1 (coté LAN) fonctionne, par contre
l'eth0 (coté net) n'arrive pas à avoir son ip en dhcp mais je penche
pour un problème au niveau de la gestion du bus PCI...
J'ai un peu googlisé pour voir s'il existait des soluces, mais je n'ai
rien trouvé de trés convaincant...
Une idée ?
Merci

@ +

Mourad

...SNIP...

Précision : un lspci -vv donne :
0000:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
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+
Latency: 64 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e800 [size%6]
Region 1: Memory at e3400000 (32-bit, non-prefetchable) [size%6]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
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+
Latency: 64 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at ec00 [size%6]
Region 1: Memory at e3401000 (32-bit, non-prefetchable) [size%6]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Ce qui semble normal pour le peu que je connaisse...

J'ai trouvé la réponse en reconfigurant le BIOS de la machine qui
faisait l'initiation de son bus PCI en "edge" et en lui forçant le
"level", mon noyau 2.6.12 retrouve ses petits...

Si quelqu'un connait le fonctionnement des bus PCI, je suis prenneur
d'un petit cours...

Salut,

C. Mourad Jaber a écrit :

J'ai trouvé la réponse en reconfigurant le BIOS de la machine qui
faisait l'initiation de son bus PCI en "edge" et en lui forçant le
"level", mon noyau 2.6.12 retrouve ses petits...

Ce qui est normal. Les lignes d'IRQ des slots PCI doivent être actives
sur niveau ("level").

Si quelqu'un connait le fonctionnement des bus PCI, je suis prenneur
d'un petit cours...

En fait le bus PCI en lui-même ne s'occupe pas du tout des
interruptions. Il prévoit 4 lignes d'interruption INTA, B, C et D par
slot, c'est tout. Dans l'architecture PC, un aiguillage programmable
(IRQ steering) permet de router les lignes d'IRQ des slots vers les
entrées du bon vieux contrôleur d'interruption, le même qu'en ISA avec
ses 16 entrées dont une grande partie sont réservées. 4 lignes fois 5
slots, ça fait 20, soit beaucoup plus que le nombre d'entrées
disponibles du contrôleur d'interruptions. Donc plusieurs lignes sont
routées sur la même IRQ, et dès qu'il y a un peu trop de périphériques
PCI ayant besoin d'une ou plusieurs IRQ, des IRQ doivent être
partagées entre deux périphériques ou plus. Le résultat est un OU
logique entre les différentes sources. Et pour partager, il est
préférable d'avoir des IRQ sur niveau plutôt que sur front. Les IRQ du
bus ISA étaient sur front, et il est bien connu qu'il ne fallait pas
les partager sous peine de gros ennuis.