Distribution: Mandrake Linux 10 AMD64 BETA1 Hardware Environment: Fujitsu-Sienems Scaleo 600 A64: Fujitsu-Siemens D1607 Mainboard with ADMtec AN983 10/100MBit Onboard LAN chip Athlon 64 3200+ (1MB L2 cache) 1GB PC2700 DDR RAM from Infinion (2x512MB) ATi Radeon 9600XT-4 300W Powersupply from Delta (200W combined power) 250GB harddrive from Maxtor 7200U/min 8MB Cache NEC ND1300A multi DVD-burner NEC 16x DVD-ROM AVM Fritz!card DSL Pinnacle PCTV TV-card Sigmatel C-Major STAC9750/51 Onboard Sound chip Software Environment: Mandrake 10 AMD64 Beta1 (64Bit) Problem Description: Tested with Mandrake 2.6.3 Kernel and Kernel 2.6.5 from www.kernel.org: Onboard LAN ADMtec AN983 is detectet by HardDrake, tulip driver seems to load normaly without any error message. But if you try to connect to another PC there is no connection. ping says: -------------------------- [mike@Scaleo mike]$ ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.349 ms wrong data byte #30 should be 0x1e but was 0x29 #16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 29 e4 22 d7 29 e4 22 d7 29 e4 22 d7 29 e4 22 d7 1e 1f #48 20 1d 1e 1f 20 21 1e 1f 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.172 ms wrong data byte #30 should be 0x1e but was 0x0 #16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 0 1 3 3 0 1 3 3 0 1 3 3 0 1 3 3 1e 1f #48 20 1d 1e 1f 20 21 1e 1f 64 bytes from 192.168.0.2: icmp_seq=3 ttl=128 time=0.162 ms wrong data byte #30 should be 0x1e but was 0xa #16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d a 4d 58 3a a 4d 58 3a a 4d 58 3a a 4d 58 3a 1e 1f #48 20 21 1e 1f 20 21 1e 1f 64 bytes from 192.168.0.2: icmp_seq=4 ttl=128 time=0.176 ms wrong data byte #30 should be 0x1e but was 0x0 #16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 0 0 c0 a8 0 0 c0 a8 0 0 c0 a8 0 0 c0 a8 1e 1f #48 20 1d 1e 1f 20 21 1e 1f 64 bytes from 192.168.0.2: icmp_seq=5 ttl=128 time=0.164 ms wrong data byte #30 should be 0x1e but was 0x50 #16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 50 0 0 0 50 0 0 0 50 0 0 0 50 0 0 0 1e 1f #48 20 21 1e 1f 20 21 1e 1f --- 192.168.0.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.162/0.204/0.349/0.074 ms ---------------------------------------------------- I installed SuSE 8.2 (32Bit version) with SuSE's patched Kernel 2.4.20 for testing. No Problems with this Kernel. tulip driver loads and i do not get any error messages fom ping. LAN connection works perfectly. So it has to be a Kernel 2.6.x problem. I know one other person yet having the same problem on a Scaleo 600 A64 and 64Bit Linux. Steps to reproduce: Install tulip driver on a Kernel 2.6.x and FSC D1607 with ADMtec AN983 Onboard LAN chip.
Created attachment 2918 [details] Patch for tulip_core.c for linux 2.6.6 This patch works for my Fujitsu-Sienems Scaleo 600 A64. It is not tested against any other architecture. While playing around i was setting the rx_copybreak to 1518 and the driver still worked. Since I do not have any deeper understanding of the tulip driver it would be nice if someone could help me assuring the patch works for other systems as well(eg. Opteron).
With same Hardware the bug persists even with recent Kernel Version 2.6.7-rc3-bk4 supplemetary output from "lspci -v": 0000:00:0b.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) Subsystem: Unknown device 1734:100c Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at 1000 Memory at b0000000 (32-bit, non-prefetchable) [size=1K] Capabilities: [c0] Power Management version 2 No problem at all with i386 kernel 2.6.4( i686 athlon) !!
Is this still a problem in 2.6.9? I have a very similar card and it appears to work well, please confirm.
Hi... I've got the same board/computer as mentioned above, running gentoo 2.6.10-r7 development sources in 64bit mode (__x86_64__) and I can confirm this thing not functioning with this kernel version. I've cross-checked that * nothing is wrong with the onboard net: it runs well with Windows * nothing is wrong with linux: it runs with an addional 3com 3c59x very well * nothing is wrong with cabling etc: I only use the same cable... With an older kernel - I don't know which version surely - around 2.6.6 or 2.6.7 and the above mentioned patch I got the network running... but now? I would offer me as a test person - if something has to be traced, I would try to trace it. That thing with the ping messages can be reproduced without problems in the same manner... ;-) Thanks a lot. - Michael
Found a - possible - solution, not knowing if this is for real: As you can see at the short "ping test" every 48-th byte is going mad and so I played a little with "ping -s xxx" with smaller and bigger sizes of the message encountering that a smaller ping size, results in a not scrambled transmission. So again - I was looking at the older kernel versions and found (with the applied patch), that it must have been - perhaps the wrong diff direction - so it shoud result now in a real code in tulip_core.c --- snip --- #if defined(__alpha__) || defined(__ia64__) static int csr0 = 0x01A00000 | 0xE000; #elif defined(__i386__) || defined(__powerpc__) || defined(__x86_64__) static int csr0 = 0x01A00000 | 0x8000; --- snip --- So I tried this configuration and everything does very well. I know there are many - even modern boards - with a onboard chip on it like 0000:00:0b.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) so many people will now be able to use this onboard network controller. Please confirm - if this is a proper solution. I for my own will use it anywhere. Annotation 2: Even with a bigger burst buffer length like ---snip--- #if defined(__alpha__) || defined(__ia64__) static int csr0 = 0x01A00000 | 0xE000; #elif defined(__i386__) || defined(__powerpc__) || defined(__x86_64__) static int csr0 = 0x01A00000 | 0x9000; ---snip--- my system is running stable. So perhaps this would improve performance a little bit.
Created attachment 4602 [details] unified patch of tulip_core.c (first original, latter patched file) the patch is a unified diff, with the first file original 2.6.10 source and the latter file the patched file in the kernel tree.
Hello Michael Polster, your patch is great. On my AMD64 computer with FS-board D1607, I can now have a network connection!!! I'm using Fedora Core 3 (64bit version). Your patch has du be included in to the kernel source. GREAT! THANKS!
I think this the patch of Michael Polster does it!
I think the patch of Michael Polster does it!
Hopefully, they will now put it in to the kernel source