2.5.20 tulip bogosities

2.5.20 tulip bogosities

[Mikael Pettersson]

With 2.5.19 tulip says the following for my 21143:

Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 5 for device 02:0a.0
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #1 config 3000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xd800, 00:40:C7:99:3A:5B, IRQ 5.

But 2.5.20 tulip now spews the following and then misidentifies
the NIC as a 21140:

Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 5 for device 02:0a.0
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media 100baseTx (#3) described by a 21140 non-MII (0) block.
tulip0:  Index #1 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
...
[136 lines deleted]
...
tulip0:  Index #139 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
tulip0:  Index #140 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
eth%d:  Invalid media table selection 255.
tulip0:  MII transceiver #1 config 3000 status 782d advertising 01e1.
eth0: Digital DS21140 Tulip rev 65 at 0xd800, 00:40:C7:99:3A:5B, IRQ 5.

Also note the obviously broken "eth%d" printk format string.

/Mikael

Re: 2.5.20 tulip bogosities

[Jeff Garzik]

Mikael,

Can you try an experiment for me?

Run 2.5.19 with the 2.5.20 tulip.  Just copy drivers/net/tulip/* from 
2.5.20 into 2.5.19.

Nothing changed in 2.5.20 tulip that should cause that, AFAICS.  So I 
want to narrow down the problem before looking further.

    Jeff

Re: 2.5.20 tulip bogosities

[Patrick Mochel]

On Thu, 6 Jun 2002, Jeff Garzik wrote:

> Mikael,
> 
> Can you try an experiment for me?
> 
> Run 2.5.19 with the 2.5.20 tulip.  Just copy drivers/net/tulip/* from 
> 2.5.20 into 2.5.19.
> 
> Nothing changed in 2.5.20 tulip that should cause that, AFAICS.  So I 
> want to narrow down the problem before looking further.

There was a bug in the PCI code that only passed the first device ID the 
driver supported to the driver's probe callback. It caused a few other 
oddities. A patch was posted to the list:

http://marc.theaimsgroup.com/?l=linux-kernel&m=102316813812289&w=2

and is now in Linus' tree. It should fix the problem, if you get a chance 
to test it...

	-pat

Re: 2.5.20 tulip bogosities

[Alessandro Suardi]

Patrick Mochel wrote:
> On Thu, 6 Jun 2002, Jeff Garzik wrote:
> 
> 
>>Mikael,
>>
>>Can you try an experiment for me?
>>
>>Run 2.5.19 with the 2.5.20 tulip.  Just copy drivers/net/tulip/* from 
>>2.5.20 into 2.5.19.
>>
>>Nothing changed in 2.5.20 tulip that should cause that, AFAICS.  So I 
>>want to narrow down the problem before looking further.
> 
> 
> There was a bug in the PCI code that only passed the first device ID the 
> driver supported to the driver's probe callback. It caused a few other 
> oddities. A patch was posted to the list:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=102316813812289&w=2
> 
> and is now in Linus' tree. It should fix the problem, if you get a chance 
> to test it...

Just wanted to restate that this patch is still not enough to
  make my Xircom PCI CardBus card work properly (xircom_cb driver).

Jun  7 12:49:24 dolphin cardmgr[597]: get dev info on socket 0 failed: Resource temporarily unavailable

All LEDs on the card never light up at all.

--alessandro

  "the hands that build / can also pull down
    even the hands of love"
                             (U2, "Exit")

Re: 2.5.20 tulip bogosities

[Thunder from the hill]

Hi,

On Thu, 6 Jun 2002, Mikael Pettersson wrote:
> Also note the obviously broken "eth%d" printk format string.

It's printk("%s: blah\n", dev->name);

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: 2.5.20 tulip bogosities

[Jeff Garzik]

Thunder from the hill wrote:

>Hi,
>
>On Thu, 6 Jun 2002, Mikael Pettersson wrote:
>  
>
>>Also note the obviously broken "eth%d" printk format string.
>>    
>>
>
>It's printk("%s: blah\n", dev->name);
>  
>

The "eth%d" thing is a format string, but unrelated to printk.  The %d 
is replaced with the ethernet interface number by the system.  That 
cosmetic bug is a holdover from olden days, when the ethernet interfaces 
would do

    register ethernet interface, get a number
    if we fail, release the number

So with the old system, it's possible that the user might be

    eth0: error cannot load, aborting [first NIC]
    eth0: error cannot load, aborting [second NIC]
    eth0: error cannot load, aborting [third NIC]

The new system, which is hotplug-friendly, makes it impossible to know 
the ethernet interface number until you _really_ are sure the NIC is ok 
to use.  Therefore, "eth%d" is "dev->name" that has not been translated 
yet.  The fix is simple, replace "eth%d" with "tulip%d" in the printk 
message, and use the board count instead of ethernet interface number.

    Jeff

Re: 2.5.20 tulip bogosities

[Mikael Pettersson]

On Thu, 6 Jun 2002 11:41:55 -0700 (PDT), Patrick Mochel wrote:
>> Run 2.5.19 with the 2.5.20 tulip.  Just copy drivers/net/tulip/* from 
>> 2.5.20 into 2.5.19.
>> 
>> Nothing changed in 2.5.20 tulip that should cause that, AFAICS.  So I 
>> want to narrow down the problem before looking further.
>
>There was a bug in the PCI code that only passed the first device ID the 
>driver supported to the driver's probe callback. It caused a few other 
>oddities. A patch was posted to the list:
>
>http://marc.theaimsgroup.com/?l=linux-kernel&m=102316813812289&w=2
>
>and is now in Linus' tree. It should fix the problem, if you get a chance 
>to test it...
>
>	-pat

The patch Pat refers to above fixed my tulip problem in 2.5.20.

For completeness I also tested 2.5.19 with 2.5.20's tulip code,
and it worked fine, as expected.

Thanks,

/Mikael