Bug 105730

Summary: Yast chooses tulip instead of de4x5 for Network card with Digital 21041 chip
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Andreas Vetter <vetter>
Component: KernelAssignee: Karsten Keil <karsten.keil>
Status: RESOLVED FIXED QA Contact: Klaus Kämpf <kkaempf>
Severity: Normal    
Priority: P5 - None CC: asklein, mvidner
Version: RC 1   
Target Milestone: ---   
Hardware: i386   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: hwinfo
y2logs.tgz
Proposed patch
messages from patched beta 3

Description Andreas Vetter 2005-08-18 23:35:40 UTC
When I install yast chooses tulip instead of de4x5 driver for my network card.
With tulip network card does not work at all, while saying link is up.
With de4x5 card works fine.
Will attach hwinfo and y2logs.
Comment 1 Andreas Vetter 2005-08-18 23:39:56 UTC
Created attachment 46619 [details]
hwinfo
Comment 2 Andreas Vetter 2005-08-18 23:40:27 UTC
Created attachment 46620 [details]
y2logs.tgz
Comment 3 Andreas Vetter 2005-08-18 23:47:11 UTC
Machine even hung up with the tulip module, when I pulled out network cable. No
Oops available, because keyboard didn't react any longer.
Comment 4 Arvin Schnell 2005-08-19 08:20:58 UTC
hwinfo lists tulip, de4x5 and de2104x for the netword card.
Comment 5 Steffen Winterfeldt 2005-08-19 08:46:21 UTC
Does de2104x work for you? 
Comment 6 Andreas Vetter 2005-08-22 13:02:17 UTC
No, it does not work:
Aug 22 12:32:38 linux kernel: bootsplash: status on console 0 changed to on
Aug 22 12:32:38 linux kernel: BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Aug 22 12:32:39 linux kernel: eth0: enabling interface
Aug 22 12:32:40 linux kernel: eth0: set link 10baseT auto
Aug 22 12:32:40 linux kernel: eth0:    mode 0x7ffc0040, sia
0x10c4,0xffffef01,0xffffffff,0xffff0008
Aug 22 12:32:40 linux kernel: eth0:    set mode 0x7ffc0040, set sia
0xef01,0xffff,0x8
Aug 22 12:32:40 linux kernel: irq 11: nobody cared (try booting with the
"irqpoll" option)
Aug 22 12:32:40 linux kernel:  [<c013c17c>] __report_bad_irq+0x1c/0x70
Aug 22 12:32:40 linux kernel:  [<c013c26b>] note_interrupt+0x6b/0xd0
Aug 22 12:32:40 linux kernel:  [<c013bd0c>] __do_IRQ+0xbc/0xd0
Aug 22 12:32:40 linux kernel:  [<c0105658>] do_IRQ+0x38/0x60
Aug 22 12:32:40 linux kernel:  [<c0103dea>] common_interrupt+0x1a/0x20
Aug 22 12:32:40 linux kernel:  [<c013007b>] posix_cpu_timer_schedule+0xcb/0x480
Aug 22 12:32:40 linux kernel:  [<c0120b91>] __do_softirq+0x31/0xa0
Aug 22 12:32:40 linux kernel:  [<c0120c26>] do_softirq+0x26/0x30
Aug 22 12:32:40 linux kernel:  [<c010565d>] do_IRQ+0x3d/0x60
Aug 22 12:32:40 linux kernel:  [<c0103dea>] common_interrupt+0x1a/0x20
Aug 22 12:32:40 linux kernel:  [<c920fcdb>] de_set_rx_mode+0xb/0x10 [de2104x]
Aug 22 12:32:40 linux kernel:  [<c921071b>] de_init_hw+0x6b/0x80 [de2104x]
Aug 22 12:32:40 linux kernel:  [<c9210a57>] de_open+0x57/0x100 [de2104x]
Aug 22 12:32:40 linux kernel:  [<c028ead3>] dev_open+0x33/0x80
Aug 22 12:32:40 linux kernel:  [<c029007f>] dev_change_flags+0xef/0x130
Aug 22 12:32:40 linux kernel:  [<c02ceea0>] devinet_ioctl+0x570/0x5e0
Aug 22 12:32:40 linux kernel:  [<c02863cc>] sock_ioctl+0x7c/0x200
Aug 22 12:32:40 linux kernel:  [<c0286350>] sock_ioctl+0x0/0x200
Aug 22 12:32:40 linux kernel:  [<c0169936>] do_ioctl+0x16/0x60
Aug 22 12:32:40 linux kernel:  [<c0169a7f>] vfs_ioctl+0x4f/0x1c0
Aug 22 12:32:40 linux kernel:  [<c0169c27>] sys_ioctl+0x37/0x70
Aug 22 12:32:40 linux kernel:  [<c0102d1b>] sysenter_past_esp+0x54/0x79
Aug 22 12:32:40 linux kernel: handlers:
Aug 22 12:32:40 linux kernel: [<c927ae90>] (snd_audiopci_interrupt+0x0/0xd0
[snd_ens1371])
Aug 22 12:32:40 linux kernel: Disabling IRQ #11
Comment 7 Andreas Vetter 2005-08-22 13:03:11 UTC
After that de4x5 does not work, only after reboot.
Comment 8 Steffen Winterfeldt 2005-08-22 13:13:39 UTC
Ok, so much for that. 
 
I took the opportunity to rip out all the special tulip vs. de4x5 code 
from hardware detection. Because I really am fed up with this. 
 
de4x5 doesn't even have a modinfo table. 
 
Clearly, the modules should be fixed. 
Comment 9 Andreas Gruenbacher 2005-08-22 13:51:06 UTC
Olaf, the drivers are all from upstream: 
  
TULIP NETWORK DRIVER  
P:      Jeff Garzik  
M:      jgarzik@pobox.com  
L:      tulip-users@lists.sourceforge.net  
W:      http://sourceforge.net/projects/tulip/  
S:      Maintained  
  
modinfo gives this, which doesn't look correct:  
  
filename:       /lib/modules/2.6.13-rc6-git13-20050822115352-smp/kernel/drivers/net/tulip/de2104x.ko  
version:        0.7  
license:        GPL  
description:    Intel/Digital 21040/1 series PCI Ethernet driver  
author:         Jeff Garzik <jgarzik@pobox.com>  
srcversion:     B42890353151EC4B3D39700  
alias:          pci:v00001011d00000014sv*sd*bc*sc*i*  
alias:          pci:v00001011d00000002sv*sd*bc*sc*i*  
depends:  
supported:      yes  
vermagic:       2.6.13-rc6-git13-20050822115352-smp SMP gcc-4.0  
parm:           debug:de2104x bitmapped message enable number (int)  
parm:           rx_copybreak:de2104x Breakpoint at which Rx packets are copied  
(int)  
  
filename:       /lib/modules/2.6.13-rc6-git13-20050822115352-smp/kernel/drivers/net/tulip/de4x5.ko  
license:        GPL  
srcversion:     35E92A21A0444DD88A2A013  
depends:  
supported:      yes  
vermagic:       2.6.13-rc6-git13-20050822115352-smp SMP gcc-4.0  
parm:           io:de4x5 I/O base address (int)  
parm:           de4x5_debug:de4x5 debug mask (int)  
parm:           dec_only:de4x5 probe only for Digital boards (0-1) (int)  
parm:           args:de4x5 full duplex and media type settings; see de4x5.c  
for details (charp)  
  
filename:       /lib/modules/2.6.13-rc6-git13-20050822115352-smp/kernel/drivers/net/tulip/tulip.ko  
version:        1.1.13-NAPI  
license:        GPL  
description:    Digital 21*4* Tulip ethernet driver  
author:         The Linux Kernel Team  
srcversion:     5E47549F6D897A256549B13  
alias:          pci:v000014EAd0000AB08sv*sd*bc*sc*i*  
alias:          pci:v000010B7d00009300sv*sd*bc*sc*i*  
alias:          pci:v000010B9d00005263sv*sd*bc*sc*i*  
alias:          pci:v000010B9d00005261sv*sd*bc*sc*i*  
alias:          pci:v000017B3d0000AB08sv*sd*bc*sc*i*  
alias:          pci:v00001737d0000AB08sv*sd*bc*sc*i*  
alias:          pci:v00001737d0000AB09sv*sd*bc*sc*i*  
alias:          pci:v00001626d00008410sv*sd*bc*sc*i*  
alias:          pci:v000014F1d00001803sv*sd*bc*sc*i*  
alias:          pci:v00001186d00001591sv*sd*bc*sc*i*  
alias:          pci:v00001186d00001561sv*sd*bc*sc*i*  
alias:          pci:v00001186d00001541sv*sd*bc*sc*i*  
alias:          pci:v00001113d00009511sv*sd*bc*sc*i*  
alias:          pci:v00001113d00001217sv*sd*bc*sc*i*  
alias:          pci:v00001113d00001216sv*sd*bc*sc*i*  
alias:          pci:v00001282d00009102sv*sd*bc*sc*i*  
alias:          pci:v00001282d00009100sv*sd*bc*sc*i*  
alias:          pci:v00008086d00000039sv*sd*bc*sc*i*  
alias:          pci:v000011F6d00009881sv*sd*bc*sc*i*  
alias:          pci:v00001259d0000A120sv*sd*bc*sc*i*  
alias:          pci:v0000104Ad00002774sv*sd*bc*sc*i*  
alias:          pci:v0000104Ad00000981sv*sd*bc*sc*i*  
alias:          pci:v000013D1d0000AB08sv*sd*bc*sc*i*  
alias:          pci:v000013D1d0000AB03sv*sd*bc*sc*i*  
alias:          pci:v000013D1d0000AB02sv*sd*bc*sc*i*  
alias:          pci:v00001317d00009511sv*sd*bc*sc*i*  
alias:          pci:v00001317d00001985sv*sd*bc*sc*i*  
alias:          pci:v00001317d00000985sv*sd*bc*sc*i*  
alias:          pci:v00001317d00000981sv*sd*bc*sc*i*  
alias:          pci:v000011ADd0000C115sv*sd*bc*sc*i*  
alias:          pci:v0000125Bd00001400sv*sd*bc*sc*i*  
alias:          pci:v000010D9d00000531sv*sd*bc*sc*i*  
alias:          pci:v000010D9d00000512sv*sd*bc*sc*i*  
alias:          pci:v000011ADd00000002sv*sd*bc*sc*i*  
alias:          pci:v00001011d00000019sv*sd*bc*sc*i*  
alias:          pci:v00001011d00000009sv*sd*bc*sc*i*  
depends:  
supported:      yes  
vermagic:       2.6.13-rc6-git13-20050822115352-smp SMP gcc-4.0  
parm:           tulip_debug:int  
parm:           max_interrupt_work:int  
parm:           rx_copybreak:int  
parm:           csr0:int  
parm:           options:array of int  
parm:           full_duplex:array of int  
Comment 10 Olaf Kirch 2005-08-22 14:10:06 UTC
I'm blind. What part of the above doesn't look right? 
 
The de4x5 and tulip drivers claim to support pretty much the same set of 
devices, but neither of them has ever work to complete satisfaction. 
 
I hate to say it, but buying a more recent network card may be the best 
way to solve this issue. 
Comment 11 Andreas Gruenbacher 2005-08-22 14:14:29 UTC
de4x5.ko doesn't have device aliases, so it won't be chosen. Do we care? 
Comment 12 Olaf Kirch 2005-08-22 14:27:57 UTC
Ah, I understand. 
 
Well, it seems the decision Jeff or someone else made was that by 
default, the tulip driver should be chosen over the de4x5 one (and I 
think that is probably a good decision). 
 
Andreas, maybe we should instead focus on finding out why your card 
doesn't work with the tulip driver. Did you try asking on netdev? 
 
Karsten, can you help Andreas? 
 
Comment 13 Karsten Keil 2005-08-22 15:54:08 UTC
hmm, so far I see, the correct driver should be de2104x.ko, this is only 
which has matching IDs 1011/0014. 
So question is why it do not get the IRQ right. It looks like the driver do 
not install a IRQ handler, but enables interrupts. 
 
Comment 14 Andreas Vetter 2005-08-22 17:40:16 UTC
Hmm, switching from de4x5 to tulip with yast results in loss of link.
 
Somehow the tulip driver does not detect the card at all.
I added tulip to initrd and rebooted. When tulip was loaded, only the driver
version was printed. Later de2104x was loaded by something (perhaps coldplug?),
this seems to find the card at least, but later i get the problem with the
interrupt nobody cared (see comment #6).

What should i try next?
Comment 15 Olaf Kirch 2005-09-01 11:13:40 UTC
The problem is that the driver enables IRQs before calling request_irq. 
Does the following patch help? 
Comment 16 Olaf Kirch 2005-09-01 11:14:28 UTC
Created attachment 48432 [details]
Proposed patch
Comment 17 Andreas Vetter 2005-09-01 12:52:28 UTC
will try during weekend with beta4
Comment 18 Olaf Kirch 2005-09-05 19:34:56 UTC
Any news? 
Comment 19 Andreas Vetter 2005-09-05 22:12:22 UTC
yes. tried in beta 3 (no time for beta 4 yet).

The patch does not help, symptoms are the same. Will attach /var/log/messages.
Comment 20 Andreas Vetter 2005-09-05 22:17:07 UTC
Created attachment 48859 [details]
messages from patched beta 3
Comment 21 Andreas Vetter 2005-09-05 22:27:07 UTC
any ideas?
Comment 22 Olaf Kirch 2005-09-07 09:30:47 UTC
Are you sure you booted the correct kernel? The log file says that the 
interrupt arrived in de_init_hw 
 
Sep  6 00:47:58 schipper kernel: irq 11: nobody cared 
[..] 
Sep  6 00:47:58 schipper kernel:  [<d132a71b>] de_init_hw+0x6b/0x80 [de2104x] 
[...] 
Sep  6 00:47:58 schipper kernel: handlers: 
Sep  6 00:47:58 schipper kernel: [<d133de90>] (snd_audiopci_interrupt+0x0/0xd0 
[snd_ens1371]) 
 
In other words, there's no interrupt handler installed for the NIC. 
 
With my patch however, there's a request_irq call _before_ the call to 
de_init_hw, so the kernel log should at least show the de_interrupt handler 
in addition to the sound handler. 
Comment 23 Andreas Vetter 2005-09-09 09:39:06 UTC
Tried again with RC1.
Behaviour is different:
The machine can still use no network. It cannot ping a working machine on the
same subnet.
There are no more messages in /var/log/messages about interupts.
Comment 24 Andreas Vetter 2005-09-09 10:32:07 UTC
Ah, stop. It works after an additional reboot.

So what I did was:
update from beta4 to rc1 from NFS. needed manual mode to select de4x5.
patched kernel, installed it, unconfigured network card with yast.
reboot
de2104x is loaded automatically (not in initrd)
configure network with yast => ping does not work
reboot => ping does work
Comment 25 Olaf Kirch 2005-09-09 13:03:10 UTC
So can we close this as resolved/fixed, or does the NIC always need 
a warm boot before the card works properly? 
Comment 26 Andreas Vetter 2005-09-09 14:28:58 UTC
works even after a cold boot
Comment 27 Olaf Kirch 2005-09-09 15:31:12 UTC
Great! So closing this one as fixed.