Re: Problem with 2.6.22 kernel

On Sun, 2007-09-09 at 09:22 +0100, Mark Sansome wrote:

> > > eth1: firmware version 8.101.5-84
> > 
> > There is no firmware with major version 8.  I assumed that the first two
> > numbers (major and minor version) would match the versions provided by
> > Atmel in the text files from which the binary files are generated.
> > 
> I don't understand this bit... 

There is no loadable firmware with such version.  In fact, all versions
start with 0 or 1.  If the driver loads the firmware, it reads the
version from the firmware file, then loads the firmware, then reads the
firmware version from the device and compares two first numbers to make
sure that the firmware has been loaded successfully.

The original test would compare all numbers with 0, but I wanted to
strengthen the test.  On my hardware, the third number would mismatch,
but I assumes that the first two numbers would not.

I understand that either the firmware doesn't need to be loaded for your
hardware, or the version actually starts with "1", but the message was
corrupted.

> > Since the version mismatch wasn't detected (at least it didn't prevent
> > registering the interface), I assume that either you have a device that
> > doesn't require firmware download, or you are not using version 0.16 as
> > published on berlios.de, or the kernel messages got corrupted somewhere.
> All I can tell you is that I have a Belkin F5D6050 and:
> > >Atmel at76x USB Wireless LAN Driver 0.16 loading
> that I got the latest driver from cvs

That's equivalent to version 0.16, which excludes some other
possibilities.

> > This change was made by Guido Guenther with the log message "remove
> > netdev_name, names of network devices can be set via udev".  It's
> > unfortunate that I didn't look at that commit.  Even though removing the
> > parameter was justified, I don't think changing the default name was a
> > good idea.
> > 
> > I guess the intention was to use names starting with "wlan" only for
> > drivers based on mac80211 stack.  Since the mac80211 conversion is
> > underway, the problem can be expected to be fixed in the next release.
> When (roughly) might this be?

It's hard to say.  The current code can only receive information, but
not transmit.  I think it would take a couple of months.

> > > How do I correct this?
> > 
> > The answer is generally specific to the distribution.  It's possible to
> > use ifrename that comes with wireless tools.  Fedora makes it possible
> > to specify MAC address for the device, and if the device with that MAC
> > address is named differently, it will be renamed.
> > 
> > Perhaps the easies approach would be just to accept that the device is
> > called eth1 now.
> 
> I might need some help with this.
> 
> I'm looking into ifrename at the moment...
> 
> If I simply accept that wlan0->eth1 I will need to change some
> configurations. In the following locations:
> /etc/sysconfig/network-scripts/
> /etc/sysconfig/networking/devices/
> /etc/sysconfig/networking/profiles/default/
> I have the files:
> ifcfg-wlan0
> keys-wlan0
> route-wlan0
> I have tried copying each of those to *-eth1 in all of the above
> locations and rebooting but still the startup screen is full of "Device
> not found" messages relating to wlan0 so I guess it is not as simple as
> all that.

I think you would need to look inside those files and replace eth1 with
wlan0.

I'm considering making a bugfix release that would restore the wlan0
name, but I'd like to see if more problems are reported.

> What else do I need to do to make it think that that wlan0 is eth1? (or
> should I simply pursue the ifrename solution?)

Normally, Fedora and related systems would just rename the device if
there is a configuration with matching HWADDR.  That is, if you have
configuration for wlan0 and it includes HWADDR=MAC, and that MAC address
is found on eth1, it would be renamed to wlan0.  It should be absolutely
transparent, but it's not working for you.

Since I don't know why it's not working, I cannot be confident that any
particular approach would help.

You could try running system-config-network, which is supposed to create
all those files.

-- 
Regards,
Pavel Roskin