Bug 7133
| Summary: | (patch queued) ibmmtr_cs:seems working as fine with 64bit kernel than with 32bits | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Yves L'ECUYER (yves.lecuyer) |
| Component: | Network | Assignee: | Alan (alan) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | low | CC: | protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.17 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
Probably needs review by those with knowledge of TR architecture. Will cc to linux-tr@linuxtr.net Any update on this bug please. Yves, is the new kernel still showing this problem? Thanks. Patch queued In for 2.6.28 |
Most recent kernel where this bug did not occur: Distribution: Fedora Core 4 and RedHat EL 4 Hardware Environment: IBM Turbo 16/4 TokenRing PC Card2 Software Environment: kernel 2.6.16 from Fedora updates Problem Description: Why to limitate in drivers/net/pcmcia/Kconfig the usage of ibmtr_cs to 32 bits arch ? In the lines: ---------- config PCMCIA_IBMTR tristate "IBM PCMCIA tokenring adapter support" depends on NET_PCMCIA && IBMTR!=y && TR && PCMCIA && !64BIT ----------------- I removed with a the limitation "&& !64BIT"; then the module compile fine with few warning, and loads fine with PCMCIA cardmanager service. I noticed than the PC used in stand alone, the TokenRing initialisation abort because the drivers says there is no Ring controller. So I used the RHEL4 with 32 bit kernel, and the corresponding ibmtr_cs, and I got the same message. So the ring controller funtionality seams not implemented in this drivers, but it's not a matter of architecture. Conclusion:I used this drivers during more than 3 weeks now, with a cisco 2504 in the ring (who plays the ring controller role fine), and the communication between my laptop (ASUS A6Q00K with TURION 64bits and Fedora Core 4/kernel 2.6.16-64bits )and the cisco 2504 is fine; protocole tested: ICMP,TCP,UDP,OSPF