Hi,
I got my hands on a Texas Instruments ThunderLAN PCI 100 Mbit card (PCI
ID 104c:0500), which is what SGI are supplying if you want a second NIC
in your O2. It appears that this card is not supported by the tlan
driver in the Linux kernel (at least not in 2.4.29, which is what I am
using on the machine I tried it on). Patching the driver with the
relevant PCI IDs allowed the detection of the card, as shown in dmesg:
ThunderLAN driver v1.15
TLAN: eth0 irq=15, io=8400, Compaq NetFlex-3/E, Rev. 48
TLAN: 1 device installed, PCI: 1 EISA: 0
and in "ifconfig eth0":
eth0 Link encap: Ethernet HWaddr 00:00:58:01:55:53
(and the rest of the normal stuff)
but trying to configure the interface with an address and bringing
it up caused a kernel oops. (This is on Alpha.)
# ifconfig eth0 inet blah... up
Unable to handle kernel paging request at virtual address 00000000093fcb04
Segmentation fault
In dmesg, there is an
ifconfig(4218): Oops 0
followed by a register dump, a trace, and some code.
Any ideas?
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
Can you send me the oops capture ??
Atro Tossavainen wrote:
> Hi,
>
> I got my hands on a Texas Instruments ThunderLAN PCI 100 Mbit card (PCI
> ID 104c:0500), which is what SGI are supplying if you want a second NIC
> in your O2. It appears that this card is not supported by the tlan
> driver in the Linux kernel (at least not in 2.4.29, which is what I am
> using on the machine I tried it on). Patching the driver with the
> relevant PCI IDs allowed the detection of the card, as shown in dmesg:
>
> ThunderLAN driver v1.15
> TLAN: eth0 irq=15, io=8400, Compaq NetFlex-3/E, Rev. 48
> TLAN: 1 device installed, PCI: 1 EISA: 0
>
> and in "ifconfig eth0":
>
> eth0 Link encap: Ethernet HWaddr 00:00:58:01:55:53
>
> (and the rest of the normal stuff)
>
> but trying to configure the interface with an address and bringing
> it up caused a kernel oops. (This is on Alpha.)
>
> # ifconfig eth0 inet blah... up
> Unable to handle kernel paging request at virtual address 00000000093fcb04
> Segmentation fault
>
> In dmesg, there is an
>
> ifconfig(4218): Oops 0
> followed by a register dump, a trace, and some code.
>
> Any ideas?
>
--
P.Lavin
Software Engineer,
Redpine Signals ,Inc.
Hyderabad.
http://www.redpinesignals.com
Try with 2.6.x - I'm not sure the 64bit cleanness stuff ever all got
into the 2.4 driver version.
Alan
On Mon, Apr 25 2005, Alan Cox wrote:
> Try with 2.6.x - I'm not sure the 64bit cleanness stuff ever all got
> into the 2.4 driver version.
Yeah the 2.6 version is your best bet. Allthough, I haven't tried it on an
Alpha in a long time.
BTW. I'm not maintaining the driver anymore. Samuel Chessman ([email protected])
took over maintainership, but I'm not sure if he's still active.
Torben
In general, just adding the device id to a driver in order to enable
it for a new device is not sufficient. They may (in most cases, will)
be additional logic that is needed in the driver to correctly enable
the new device. If this is the case, I'd expect the patched driver to
fail on open even with the 2.6 kernel.
ganesh.
On 4/25/05, Torben Mathiasen <[email protected]> wrote:
> On Mon, Apr 25 2005, Alan Cox wrote:
> > Try with 2.6.x - I'm not sure the 64bit cleanness stuff ever all got
> > into the 2.4 driver version.
>
> Yeah the 2.6 version is your best bet. Allthough, I haven't tried it on an
> Alpha in a long time.
>
> BTW. I'm not maintaining the driver anymore. Samuel Chessman ([email protected])
> took over maintainership, but I'm not sure if he's still active.
>
> Torben
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, Apr 25 2005, Ganesh Venkatesan wrote:
> In general, just adding the device id to a driver in order to enable
> it for a new device is not sufficient. They may (in most cases, will)
> be additional logic that is needed in the driver to correctly enable
> the new device. If this is the case, I'd expect the patched driver to
> fail on open even with the 2.6 kernel.
>
Absolutely, but the TLAN parts are usually quite alike. Even when the EISA
support was added, only the probing was changed to accomodate those cards.
I remember trying the TLAN's on an alpha a few years ago, and IIRC the 64bit
support was lacking badly. I know some of this has been changed in the 2.6
version of the driver, but it may not work very well since so few people use
this combination.
Thanks,
Torben