ipw2100: firmware problem

ipw2100: firmware problem

[Pavel Machek]

Hi!

I'm fighting with firmware problem: if ipw2100 is compiled into
kernel, it is loaded while kernel boots and firmware loader is not yet
available. That leads to uninitialized (=> useless) adapter.

What's the prefered way to solve this one? Only load firmware when
user does ifconfig eth1 up? [It is wifi, it looks like it would be
better to start firmware sooner so that it can associate to the
AP...].

Last initcall available in kernel is late_initcall; that's not late
enough for me. Is adding one more initcall that is started when
userland is available a solution?
								Pavel

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> Hi!
> 
> I'm fighting with firmware problem: if ipw2100 is compiled into
> kernel, it is loaded while kernel boots and firmware loader is not yet
> available. That leads to uninitialized (=> useless) adapter.
> 
> What's the prefered way to solve this one? Only load firmware when
> user does ifconfig eth1 up? [It is wifi, it looks like it would be
> better to start firmware sooner so that it can associate to the
> AP...].

Do you want to associate to an AP when your kernel boots,
_before_ any iwconfig had a chance to configure anything?
That's strange.

My position is that wifi drivers must start up in an "OFF" mode.
Do not send anything. Do not join APs or start IBSS.
Thus, no need to load fw in early boot.

Driver may load firmware and start actively doing something
only when iwconfig gets executed and thus driver is
instructed what to do.

Some drivers currently do not act this way, and thus
less advanced users may unknowingly run a wireless STA
(or worse, an AP!) on their notebook for years, interfering
with neighbors and/or violating local regulations (there are
countrles where 802.11 use needs licensing).
--
vda

Re: ipw2100: firmware problem

[Jirka Bohac]

On Wed, Jun 08, 2005 at 05:44:20PM +0300, Denis Vlasenko wrote:
> On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > What's the prefered way to solve this one? Only load firmware when
> > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > better to start firmware sooner so that it can associate to the
> > AP...].
> 
> Do you want to associate to an AP when your kernel boots,
> _before_ any iwconfig had a chance to configure anything?
> That's strange.
> 
> My position is that wifi drivers must start up in an "OFF" mode.
> Do not send anything. Do not join APs or start IBSS.

Agreed.

> Thus, no need to load fw in early boot.

I don't think this is true. Loading the firmware on the first
"ifconfig up" is problematic. Often, people want to rename the
device from ethX/wlanX/... to something stable. This is usually
based on the adapter's MAC address, which is not visible until
the firmware is loaded.

Prism54 does it this way and it really sucks. You need to bring
the adapter up to load the firmware, then bring it back down,
rename it, and bring it up again.

Denis: any plans for this to be fixed?

I agree that drivers should initialize the adapter in the OFF
state, but the firmware needs to be loaded earlier than the
first ifconfig up.

How about loading the firmware when the first ioctl touches the
device? This way, it would get loaded just before the MAC address
is retrieved.

regards,

-- 
Jirka Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CR

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > Hi!
> >
> > I'm fighting with firmware problem: if ipw2100 is compiled into
> > kernel, it is loaded while kernel boots and firmware loader
> is not yet
> > available. That leads to uninitialized (=> useless) adapter.

Pavel,

	I might be lost here but... How is the firmware loaded when using the
ipw2100-1.0.0/patches Kernel patch?

That patch normally works fine. It might not be the way you kernel
developers would like it, but maybe that could work the same way?


> >
> > What's the prefered way to solve this one? Only load firmware when
> > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > better to start firmware sooner so that it can associate to the
> > AP...].
>
> Do you want to associate to an AP when your kernel boots,
> _before_ any iwconfig had a chance to configure anything?
> That's strange.

Currently, when we install the driver, it associates to any open network on
boot. This is good, cause we don't want to be typing the commands all the
time just to associate. It works this way now and is pretty nice.

>
> My position is that wifi drivers must start up in an "OFF" mode.
> Do not send anything. Do not join APs or start IBSS.
> Thus, no need to load fw in early boot.
>
So, to scan a network, I would have to do ifconfig eth1 up ; iwlist eth1
scan?
When moving from modes with the firmwares, would I have to do ifconfig eth1
up ; iwconfig eth1 mode monitor? or would the firmware be loaded with
iwconfig? Does it have that function?

I'm not sure, but I guess that you guys should use the same method that the
source/patches uses?

.Alejandro

Re: ipw2100: firmware problem

[Jiri Benc]

On Wed, 8 Jun 2005 09:05:27 -0600, Alejandro Bonilla wrote:
> 	I might be lost here but... How is the firmware loaded when using the
> ipw2100-1.0.0/patches Kernel patch?

It is loaded by request_firmware() during initialization of the adapter.
That doesn't work, as at that time no hotplug binary can be executed (we
are talking about ipw2100 built in the kernel, not built as a module).

> Currently, when we install the driver, it associates to any open network on
> boot. This is good, cause we don't want to be typing the commands all the
> time just to associate. It works this way now and is pretty nice.

It sounds very dangerous to me.

> So, to scan a network, I would have to do ifconfig eth1 up ; iwlist eth1
> scan?

No. Driver should request the firmware when it is told to perform a scan.

> When moving from modes with the firmwares, would I have to do ifconfig eth1
> up ; iwconfig eth1 mode monitor? or would the firmware be loaded with
> iwconfig? Does it have that function?

Firmware can be loaded automatically by the driver when there is some
request from userspace and the firmware has not been loaded yet.


-- 
Jiri Benc
SUSE Labs

Re: ipw2100: firmware problem

[Tomasz Torcz]

On Wed, Jun 08, 2005 at 04:56:53PM +0200, Jirka Bohac wrote:
> I don't think this is true. Loading the firmware on the first
> "ifconfig up" is problematic. Often, people want to rename the
> device from ethX/wlanX/... to something stable. This is usually
> based on the adapter's MAC address, which is not visible until
> the firmware is loaded.
 
> I agree that drivers should initialize the adapter in the OFF
> state, but the firmware needs to be loaded earlier than the
> first ifconfig up.
> 
> How about loading the firmware when the first ioctl touches the
> device? This way, it would get loaded just before the MAC address
> is retrieved.

 Best way to rename network adapter is to use udev. So MAC must be
available (and present in /sysfs) when hotplug event for adapter is
generated.

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
zdzichu@irc.-nie.spam-.pl     Your routes will be aggreggated. -- Alex Yuriev

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> > Do you want to associate to an AP when your kernel boots,
> > _before_ any iwconfig had a chance to configure anything?
> > That's strange.
> > 
> > My position is that wifi drivers must start up in an "OFF" mode.
> > Do not send anything. Do not join APs or start IBSS.
> 
> Agreed.

Me too ;-).

> > Thus, no need to load fw in early boot.
> 
> I don't think this is true. Loading the firmware on the first
> "ifconfig up" is problematic. Often, people want to rename the
> device from ethX/wlanX/... to something stable. This is usually
> based on the adapter's MAC address, which is not visible until
> the firmware is loaded.
> 
> Prism54 does it this way and it really sucks. You need to bring
> the adapter up to load the firmware, then bring it back down,
> rename it, and bring it up again.
> 
> Denis: any plans for this to be fixed?
> 
> I agree that drivers should initialize the adapter in the OFF
> state, but the firmware needs to be loaded earlier than the
> first ifconfig up.
> 
> How about loading the firmware when the first ioctl touches the
> device? This way, it would get loaded just before the MAC address
> is retrieved.

Thats really ugly :-(.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: ipw2100: firmware problem

[James Ketrenos]

Pavel Machek wrote:

>Hi!
>
>I'm fighting with firmware problem: if ipw2100 is compiled into
>kernel, it is loaded while kernel boots and firmware loader is not yet
>available. That leads to uninitialized (=> useless) adapter.
>  
>
We've been looking into whether the initrd can have the firmware affixed
to the end w/ some magic bytes to identify it.  If it works, enhancing
the request_firmware to support both hotplug and an initrd approach may
be reasonable.

>What's the prefered way to solve this one? Only load firmware when
>user does ifconfig eth1 up? [It is wifi, it looks like it would be
>better to start firmware sooner so that it can associate to the
>AP...].
>  
>
The debate goes back and forth on whether devices should come up only
after they are told, or initialize and start looking for a network as
soon as the module is loaded.

I lean more toward having the driver just do what it is told, defaulting
to trying to scan and associate so link is ready as soon as possible. 
We've added module parameters to change that behavior (disable and
associate for the ipw2100).

James

Re: ipw2100: firmware problem

[James Ketrenos]

Denis Vlasenko wrote:

>My position is that wifi drivers must start up in an "OFF" mode.
>Do not send anything. Do not join APs or start IBSS.
>Thus, no need to load fw in early boot.
>  
>
This should be an option for the user if that is the desired behavior. 
We support that with the ipw2100 and ipw2200 projects via module
parameters to disable the radio during module load.  Having a standard
module parameter for wireless drivers would be nice.

My approach is to make the driver so it supports as many usage models as
possible, leaving policy to other components of the system.  If the user
wants it to scan and associate immediately, that should be supported. 
Likewise if they want the module to be loaded w/ the radio off, they can
do that as well.

Since most (if not all) laptops support an RF kill switch, I tend to
defer to the physical switch as the user's point of control and set the
driver defaults to try and use the radio if it is enabled.

James

Re: ipw2100: firmware problem

[David S. Miller]

From: James Ketrenos <jketreno@linux.intel.com>
Date: Wed, 08 Jun 2005 12:10:37 -0500

> My approach is to make the driver so it supports as many usage models as
> possible, leaving policy to other components of the system.

I don't see how this kind of firmware load setup handles something
like an NFS root over such a device that requires firmware.

And let's not mention that I have to setup an initrd to make that
work, that's rediculious.

This is the kind of crap that happens when drivers in the kernel
are not self contained, and need "external stuff" to work properly.
It means that simple things like NFS root over the device do not
work in a straightforward, simple, and elegant manner.

I am likely to always take the position that device firmware
belongs in the kernel proper, not via these userland and filesystem
loading mechanism, none of which may be even _available_ when
we first need to get the device going.

Re: ipw2100: firmware problem

[Dave Jones]

On Wed, Jun 08, 2005 at 12:43:32PM -0700, David S. Miller wrote:
 
 > I am likely to always take the position that device firmware
 > belongs in the kernel proper, not via these userland and filesystem
 > loading mechanism, none of which may be even _available_ when
 > we first need to get the device going.

FWIW, I agree, though the licensing of the Intel firmware
prevents that iirc.  The biggest problem I face with this driver
in Fedora kernels is users mismatching firmware rev with the
driver version. Another problem that disappears if the two
are shipped together.

Of course this would then bring out the armchair lawyers on
the list and cause another 500 emails debating whether it
violates the gpl.

		Dave

Re: ipw2100: firmware problem

[David S. Miller]

From: Dave Jones <davej@redhat.com>
Date: Wed, 8 Jun 2005 15:49:02 -0400

> FWIW, I agree, though the licensing of the Intel firmware
> prevents that iirc.  The biggest problem I face with this driver
> in Fedora kernels is users mismatching firmware rev with the
> driver version. Another problem that disappears if the two
> are shipped together.

Yep, this license definitely hurts users, in many many ways.

If this kind of external firmware requirement existed for a popular
SCSI controller, more people would be up in arms about this and
understand the issue more clearly.

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> >I'm fighting with firmware problem: if ipw2100 is compiled into
> >kernel, it is loaded while kernel boots and firmware loader is not yet
> >available. That leads to uninitialized (=> useless) adapter.
> >  
> >
> We've been looking into whether the initrd can have the firmware affixed
> to the end w/ some magic bytes to identify it.  If it works, enhancing
> the request_firmware to support both hotplug and an initrd approach may
> be reasonable.

That seems pretty ugly to me... imagine more than one driver does this
:-(.

> >What's the prefered way to solve this one? Only load firmware when
> >user does ifconfig eth1 up? [It is wifi, it looks like it would be
> >better to start firmware sooner so that it can associate to the
> >AP...].
> >  
> >
> The debate goes back and forth on whether devices should come up only
> after they are told, or initialize and start looking for a network as
> soon as the module is loaded.
> 
> I lean more toward having the driver just do what it is told, defaulting
> to trying to scan and associate so link is ready as soon as possible. 
> We've added module parameters to change that behavior (disable and
> associate for the ipw2100).

Having a parameter to control this seems a bit too complex to me.

How is 

insmod ipw2100 enable=1

different from

insmod ipw2100
iwconfig eth1 start_scanning_or_whatever

?

								Pavel

Re: ipw2100: firmware problem

[James Ketrenos]

Pavel Machek wrote:

>>We've been looking into whether the initrd can have the firmware affixed
>>to the end w/ some magic bytes to identify it.  If it works, enhancing
>>the request_firmware to support both hotplug and an initrd approach may
>>be reasonable.
>>    
>>
>
>That seems pretty ugly to me... imagine more than one driver does this
>:-(.
>  
>
Not ideal, but not *that bad* if there is a standard way to stick the
data on the initrd image.  Its annoying to have to do it, but it does
enable the most usage models and allows the network to be brought up as
early as possible--which other components in the system may be relying on.

>Having a parameter to control this seems a bit too complex to me.
>
>How is 
>
>insmod ipw2100 enable=1
>
>different from
>
>insmod ipw2100
>iwconfig eth1 start_scanning_or_whatever
>
>?
>  
>
It defaults to enabled, so you just need to do:

    insmod ipw2100

and it will auto associate with an open network.  For the use case where
users want the device to load but not initialize, they can use

    insmod ipw2100 disable=1

If hotplug and firmware loading worked early in the init sequence, no
one would have issue with the current model; it works as users expect it
to work.  It magically finds and associates to networks, and your
network scripts can then kick off DHCP, all with little to no special
crafting or utility interfacing. 

James

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> >Having a parameter to control this seems a bit too complex to me.
> >
> >How is 
> >
> >insmod ipw2100 enable=1
> >
> >different from
> >
> >insmod ipw2100
> >iwconfig eth1 start_scanning_or_whatever
> >
> >?
> It defaults to enabled, so you just need to do:
> 
>     insmod ipw2100
> 
> and it will auto associate with an open network.  For the use case where
> users want the device to load but not initialize, they can use
> 
>     insmod ipw2100 disable=1
> 
> If hotplug and firmware loading worked early in the init sequence, no
> one would have issue with the current model; it works as users expect it
> to work.  It magically finds and associates to networks, and your
> network scripts can then kick off DHCP, all with little to no special
> crafting or utility interfacing. 

Actually it would still transmit when user did not want it to. I
believe that staying "quiet" is right thing, long-term. And it could
solve firmware-loading problems, short-term...

How long does association with AP take? Anyway it should be easy to
tell driver to associate ASAP, just after the insmod...
								Pavel

Re: ipw2100: firmware problem

[Zhu Yi]

Hi Pavel,

On Thu, 2005-06-09 at 00:34 +0200, Pavel Machek wrote:
> Actually it would still transmit when user did not want it to. I
> believe that staying "quiet" is right thing, long-term. And it could
> solve firmware-loading problems, short-term...

If ipw2100 is built into kernel, you can disable it by kernel parameter
ipw2100.disable=1. Then you can enable it with:

$ echo 0 > /sys/bus/pci/drivers/ipw2100/*/rf_kill

> How long does association with AP take? Anyway it should be easy to
> tell driver to associate ASAP, just after the insmod...

Are you suggesting by default it is disabled for built into kernel but
enabled as a module?

Thanks,
-yi

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Wednesday 08 June 2005 22:43, David S. Miller wrote:
> From: James Ketrenos <jketreno@linux.intel.com>
> Date: Wed, 08 Jun 2005 12:10:37 -0500
> 
> > My approach is to make the driver so it supports as many usage models as
> > possible, leaving policy to other components of the system.
> 
> I don't see how this kind of firmware load setup handles something
> like an NFS root over such a device that requires firmware.

You practically cannot avoid having initrd because you are very likely
to need to do some wifi config (at least ESSID and mode).
Well, you can, but it gets more arcane with each turn
(essid=,mode= module parameters - in each and every wifi driver!
and what if you need to set basic rates? Yet another parameter?).

It's analogous to DHCP+NFS_root boot - we do have ugly hack
of kernelspace dhcp client, but IIRC it is agreed that the Right Thing
is to do such things in userspace (if needed, via initrd/initramfs).

It simply allows for way more options what you can do in early boot
if you have early userspace.
--
vda

Re: ipw2100: firmware problem

[Jeff Garzik]

David S. Miller wrote:
> From: James Ketrenos <jketreno@linux.intel.com>
> Date: Wed, 08 Jun 2005 12:10:37 -0500
> 
> 
>>My approach is to make the driver so it supports as many usage models as
>>possible, leaving policy to other components of the system.
> 
> 
> I don't see how this kind of firmware load setup handles something
> like an NFS root over such a device that requires firmware.
> 
> And let's not mention that I have to setup an initrd to make that
> work, that's rediculious.
> 
> This is the kind of crap that happens when drivers in the kernel
> are not self contained, and need "external stuff" to work properly.
> It means that simple things like NFS root over the device do not
> work in a straightforward, simple, and elegant manner.


Actually these questions has already been answered (though I know you 
will probably grumble a bit :))

"early userspace" is the long term answer.  usr/* in the current kernel 
tree is a placeholder for an image that is shipped with the kernel, 
which provides things (kernel modules, userspace programs, firmware) 
that are necessary to boot.

The key is that it is shipped with the kernel source tree, and built 
into the kernel image, and _dropped from memory_ after init.  The entire 
process should all be automatic.

Linus ack'd the current stuff (by merging it, after some discussion) and 
would have merged klibc too, had it any users.

  ...

As to $current_thread, initramfs exists but "early userspace" does not. 
    There isn't AFAIK any infrastructure to automatically add firmware 
to initrd in any standard distribution (corrections welcome!).  So 
today, initrd+firmware is just a big pain.

Therefore, the easiest way to make things work today is to poke Intel to 
fix their firmware license so that we can distribute it with the kernel :)

	Jeff

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> 
> > On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > > Hi!
> > >
> > > I'm fighting with firmware problem: if ipw2100 is compiled into
> > > kernel, it is loaded while kernel boots and firmware loader
> > is not yet
> > > available. That leads to uninitialized (=> useless) adapter.
> 
> Pavel,
> 
> 	I might be lost here but... How is the firmware loaded when using the
> ipw2100-1.0.0/patches Kernel patch?
> 
> That patch normally works fine. It might not be the way you kernel
> developers would like it, but maybe that could work the same way?
> 
> 
> > >
> > > What's the prefered way to solve this one? Only load firmware when
> > > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > > better to start firmware sooner so that it can associate to the
> > > AP...].
> >
> > Do you want to associate to an AP when your kernel boots,
> > _before_ any iwconfig had a chance to configure anything?
> > That's strange.
> 
> Currently, when we install the driver, it associates to any open network on
> boot. This is good, cause we don't want to be typing the commands all the
> time just to associate. It works this way now and is pretty nice.

What is so nice about this? That Linux novice user with his new lappie
will join a neighbor's network every time he powers up the lappie,
even without knowing that?

That will be analogous to me plugging ethernet cable into the switch and
wanting it to work, without any IP addr config, even without DHCP client.
Just power up the box (or modprobe an eth module) and it works! Cool, eh?

For some reason, we do not do this for wired nets. Why should wireless
be different?
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:03:49 +0300

> You practically cannot avoid having initrd because you are very likely
> to need to do some wifi config (at least ESSID and mode).

I need neither at home.  It comes up by default just fine with
ifconfig.

Your points are valid, but they do not detract from the fact that
pieced up drivers, half in the kernel half somewhere else, is total
madness.  It is a lose for the user.

Re: ipw2100: firmware problem

[David S. Miller]

From: Jeff Garzik <jgarzik@pobox.com>
Date: Thu, 09 Jun 2005 02:06:05 -0400

> Therefore, the easiest way to make things work today is to poke Intel to 
> fix their firmware license so that we can distribute it with the kernel :)

Seperate firmware from the in-kernel driver is a big headache for
users.  As DaveJ has stated, people make mistakes and try to match up
the wrong firmware version with the driver and stuff like that.  And
he should know as he has to deal sift through bogus bug reports from
people running into this problem.

If it's integrated, there are no problems like this.

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:09:55 +0300

> On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> > Currently, when we install the driver, it associates to any open network on
> > boot. This is good, cause we don't want to be typing the commands all the
> > time just to associate. It works this way now and is pretty nice.
> 
> What is so nice about this? That Linux novice user with his new lappie
> will join a neighbor's network every time he powers up the lappie,
> even without knowing that?

I love this behavior, because it means that I don't have to do
anything special to get my setup at home working.

Me caveman
Me plug in wireless router
Me watch pretty lights
Me turn on computer
Me up interface
Computer work
Me no care other cavemen use wireless link

Configuration knobs are _madness_.  Things should work with minimal
intervention and configuration.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:10, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:03:49 +0300
> 
> > You practically cannot avoid having initrd because you are very likely
> > to need to do some wifi config (at least ESSID and mode).
> 
> I need neither at home.  It comes up by default just fine with
> ifconfig.
> 
> Your points are valid, but they do not detract from the fact that
> pieced up drivers, half in the kernel half somewhere else, is total
> madness.  It is a lose for the user.

Here I am totally agree. I would like to not have to mess with
separate firmware files. I even don't want binary firmware, gimme
the source!

Sadly, realities are such that we have to live somehow
with closed-source firmware. Worse, sometimes it even isn't freely
redistributable (vendor did not explicitly allowed that),
and thus we have to ship driver, but users must obtain
firmware elsewhere themself.

Thus so far we cannot avoid having split drivers.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:17:23 +0300

> Sadly, realities are such that we have to live somehow
> with closed-source firmware.

You have a choice, buy products from friendly vendors.
I use prism54 cards in my laptops for this reason.

If you like a vendor's products who aren't friendly, try
to voice intelligently your opinion to them as to why users
will benefit from them fixing the firmware situation.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:16, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:09:55 +0300
> 
> > On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> > > Currently, when we install the driver, it associates to any open network on
> > > boot. This is good, cause we don't want to be typing the commands all the
> > > time just to associate. It works this way now and is pretty nice.
> > 
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> 
> I love this behavior, because it means that I don't have to do
> anything special to get my setup at home working.
> 
> Me caveman
> Me plug in wireless router
> Me watch pretty lights
> Me turn on computer
> Me up interface

You need to up interface? And surely you need ip addr? That's a knob also! :)

> Computer work
> Me no care other cavemen use wireless link
> 
> Configuration knobs are _madness_.  Things should work with minimal
> intervention and configuration.

Sure. I consider "iwconfig essid MyCave mode managed" a minimal intervention,
just like I consider "ip a a dev eth0 123.123.123.2/24 brd +; ip l set dev eth0 up"
a miniman interventian if I need IP configured.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:25:07 +0300

> You need to up interface? And surely you need ip addr? That's a knob also! :)

There's this thing called DHCP which takes care of this for me.
With IPV6, even less configuration can be necessary.

Re: ipw2100: firmware problem

[Jeff Garzik]

David S. Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Thu, 09 Jun 2005 02:06:05 -0400
> 
> 
>>Therefore, the easiest way to make things work today is to poke Intel to 
>>fix their firmware license so that we can distribute it with the kernel :)
> 
> 
> Seperate firmware from the in-kernel driver is a big headache for
> users.  As DaveJ has stated, people make mistakes and try to match up
> the wrong firmware version with the driver and stuff like that.  And
> he should know as he has to deal sift through bogus bug reports from
> people running into this problem.
> 
> If it's integrated, there are no problems like this.

Early userspace is (a) shipped with the kernel source tree and (b) 
linked into vmlinux.  That's integrated.

The firmware images will be separate from the .c files (as they should 
be), but the kernel hacker still controls what gets loaded, and when.

But like I said, that's where we're going, not where we are now.

	Jeff

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:20, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:17:23 +0300
> 
> > Sadly, realities are such that we have to live somehow
> > with closed-source firmware.
> 
> You have a choice, buy products from friendly vendors.

I am trying! So far, I have Prism2.5, Prism54
and acx111 cards, and all of them require closed binary fw.

> I use prism54 cards in my laptops for this reason.

?! As far as I remember, it needs a fw and fw is not open...
did that change recently?
 
> If you like a vendor's products who aren't friendly, try
> to voice intelligently your opinion to them as to why users
> will benefit from them fixing the firmware situation.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:30:22 +0300

> On Thursday 09 June 2005 09:20, David S. Miller wrote:
> > I use prism54 cards in my laptops for this reason.
> 
> ?! As far as I remember, it needs a fw and fw is not open...
> did that change recently?

My bad, they are not.  You're right :-/

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:28, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:25:07 +0300
> 
> > You need to up interface? And surely you need ip addr? That's a knob also! :)
> 
> There's this thing called DHCP which takes care of this for me.
> With IPV6, even less configuration can be necessary.

But DHCP does not start by itself, and it shuldn't.
You start dhcp client. That is a "minimal config" in this case.

Anyway, I think I start trolling... I should stop now.
--
vda

Re: ipw2100: firmware problem

[Wichert Akkerman]

Previously Denis Vlasenko wrote:
> But DHCP does not start by itself, and it shuldn't.

It does in most modern distros as far as I know. They use ifplugd or a
similar tool to monitor link status and configure the interface if a link is
detected.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> > > Currently, when we install the driver, it associates to any open network on
> > > boot. This is good, cause we don't want to be typing the commands all the
> > > time just to associate. It works this way now and is pretty nice.
> > 
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> 
> I love this behavior, because it means that I don't have to do
> anything special to get my setup at home working.
> 
> Me caveman
> Me plug in wireless router
> Me watch pretty lights
> Me turn on computer
> Me up interface
> Computer work
> Me no care other cavemen use wireless link
> 
> Configuration knobs are _madness_.  Things should work with minimal
> intervention and configuration.

I'm not saying it should not work automagically. But it is wrong to
start transmitting on wireless as soon as kernel boots. It should stay
quiet in the radio until it is either told to talk or until interface
is upped.

That way 

* above still works, only radio chat begins one step later

* if you are in environment where you absolutely do not want it to
talk on the radio (airplane, BlackHatCon with APs trying to hack you
all around), you can make it quiet without needing kernel/module
parameters.

								Pavel 

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> > Actually it would still transmit when user did not want it to. I
> > believe that staying "quiet" is right thing, long-term. And it could
> > solve firmware-loading problems, short-term...
> 
> If ipw2100 is built into kernel, you can disable it by kernel parameter
> ipw2100.disable=1. Then you can enable it with:
> 
> $ echo 0 > /sys/bus/pci/drivers/ipw2100/*/rf_kill
> 
> > How long does association with AP take? Anyway it should be easy to
> > tell driver to associate ASAP, just after the insmod...
> 
> Are you suggesting by default it is disabled for built into kernel but
> enabled as a module?

I'm suggesting that by default it is disabled (in kernel or as a
module) and its automatically enabled during ifconfig up.

That way we can drop the kernel parameter and always do the right
thing.

								Pavel

Re: ipw2100: firmware problem

[Andi Kleen]

James Ketrenos <jketreno@linux.intel.com> writes:
>>
> We've been looking into whether the initrd can have the firmware affixed
> to the end w/ some magic bytes to identify it.  If it works, enhancing
> the request_firmware to support both hotplug and an initrd approach may
> be reasonable.

That space is already used in common distributions for replacement DSDTs

I guess at some point we will need a file system in there, but - oops -
we already have one, dont we? :)

-Andi

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> What is so nice about this? That Linux novice user with his new lappie
> will join a neighbor's network every time he powers up the lappie,
> even without knowing that?
>
> That will be analogous to me plugging ethernet cable into the
> switch and
> wanting it to work, without any IP addr config, even without
> DHCP client.
> Just power up the box (or modprobe an eth module) and it
> works! Cool, eh?
>

You want things one way, I like them in another way. Whoever makes this
decision should just know that we would like to have an option to make it
load with or without the ASSOC on.

James already said to use the options ipw2100 disable=1 if you don't want it
to associate everytime on boot.

At the end, who decides this?

.Alejandro


> For some reason, we do not do this for wired nets. Why should wireless
> be different?
> --
> vda
>

Re: ipw2100: firmware problem

[David S. Miller]

From: Pavel Machek <pavel@ucw.cz>
Date: Thu, 9 Jun 2005 12:42:05 +0200

> I'm not saying it should not work automagically. But it is wrong to
> start transmitting on wireless as soon as kernel boots. It should stay
> quiet in the radio until it is either told to talk or until interface
> is upped.

I agree.

There is a similar problem in the Acenic driver, it brings the
link up and receives broadcast packets as soon as the driver
is loaded.  Mostly this is because the driver inits the chip
and registers the IRQ handler at probe time, whereas nearly
every other driver does this at ->open() time.

Re: ipw2100: firmware problem

[James Ketrenos]

David S. Miller wrote:

>From: Pavel Machek <pavel@ucw.cz>
>Date: Thu, 9 Jun 2005 12:42:05 +0200
>
>  
>
>>I'm not saying it should not work automagically. But it is wrong to
>>start transmitting on wireless as soon as kernel boots. It should stay
>>quiet in the radio until it is either told to talk or until interface
>>is upped.
>>    
>>
>
>I agree.
>
>There is a similar problem in the Acenic driver, it brings the
>link up and receives broadcast packets as soon as the driver
>is loaded.  Mostly this is because the driver inits the chip
>and registers the IRQ handler at probe time, whereas nearly
>every other driver does this at ->open() time.
>  
>
The ipw2100 originally postponed doing any initialization until open was
called.  The problem at that time was that distributions were crafted to
rely on link detection (I believe via ethtoolop's get_link) before they
would bring the interface up.

With a wireless device, you don't have link until you are associated... 
chicken and egg.  The solution was to move initialization and
association to the probe.

I don't know if all the distributions have moved away from this model. 
If they have and the devices are brought up regardless of link, then
going back to delaying radio initialization until the open() is called
is workable. 

James

Re: ipw2100: firmware problem

[Olivier Galibert]

On Thu, Jun 09, 2005 at 03:56:15PM +0200, Andi Kleen wrote:
> I guess at some point we will need a file system in there, but - oops -
> we already have one, dont we? :)

Well, you could put .config in it too.

Frankly, a filesystem that:
- can be somehow linked with vmlinux and not separate like an initrd

- editable post vmlinux-linking

- gives files that can be accessed from request_firmware, acpi and
  friends even rather early in the boot process (i.e. well before any
  userland is allowed to exist)

- accessible post-boot through mounting of a special fs and/or /proc or something

would be quite useful.

  OG.

Re: ipw2100: firmware problem

[Arjan van de Ven]

On Thu, 2005-06-09 at 16:01 -0500, James Ketrenos wrote:
> I don't know if all the distributions have moved away from this model. 
> If they have and the devices are brought up regardless of link, then
> going back to delaying radio initialization until the open() is called
> is workable. 

wouldn't you want that anyway for power saving reasons?

Re: ipw2100: firmware problem

[David S. Miller]

From: James Ketrenos <jketreno@linux.intel.com>
Date: Thu, 09 Jun 2005 16:01:30 -0500

> The ipw2100 originally postponed doing any initialization until open was
> called.  The problem at that time was that distributions were crafted to
> rely on link detection (I believe via ethtoolop's get_link) before they
> would bring the interface up.

Yes, I see, and that does work for most ethernet devices.
I noticed that Debian's 3.1 installer used this to determine
which ethernet device it should use as the default in it's
network device dialogue.

One idea, returning true for get_link when the device is down, may not
be a bad idea for the wireless case.

Re: ipw2100: firmware problem

[Jeff Garzik]

Olivier Galibert wrote:
> On Thu, Jun 09, 2005 at 03:56:15PM +0200, Andi Kleen wrote:
> 
>>I guess at some point we will need a file system in there, but - oops -
>>we already have one, dont we? :)
> 
> 
> Well, you could put .config in it too.
> 
> Frankly, a filesystem that:
> - can be somehow linked with vmlinux and not separate like an initrd
> 
> - editable post vmlinux-linking
> 
> - gives files that can be accessed from request_firmware, acpi and
>   friends even rather early in the boot process (i.e. well before any
>   userland is allowed to exist)
> 
> - accessible post-boot through mounting of a special fs and/or /proc or something
> 
> would be quite useful.

This exists.  It's called initramfs.  Read the kernel code :)

	Jeff

Re: ipw2100: firmware problem

[Jeff Garzik]

James Ketrenos wrote:
> I don't know if all the distributions have moved away from this model. 
> If they have and the devices are brought up regardless of link, then
> going back to delaying radio initialization until the open() is called
> is workable. 


When the interface is not up, we ideally want the device to be as 
passive as possible.

Most net drivers shut down as much as possible at dev->close() time, and 
it would really be good if wireless drivers followed suit.

	Jeff

Re: ipw2100: firmware problem

[Alejandro Bonilla]

Jeff Garzik wrote:

> James Ketrenos wrote:
>
>> I don't know if all the distributions have moved away from this 
>> model. If they have and the devices are brought up regardless of 
>> link, then
>> going back to delaying radio initialization until the open() is called
>> is workable. 
>
>
>
> When the interface is not up, we ideally want the device to be as 
> passive as possible.
>
> Most net drivers shut down as much as possible at dev->close() time, 
> and it would really be good if wireless drivers followed suit.
>
>     Jeff
>
>
>
OK. I understand the point and I totally agree with this. We really want 
the adapter to just do what the user or profiles ask the adapter to do. 
Yes, in an ideal world.

Let's talk about easyness. These adapters are in laptops. You don't want 
to type a lot of stop everytime you move from access points, reboots and 
so on. In a server enviroment with the ethernet adapters, we really just 
want them to do what they do and we have scripts for it. So, again, with 
mobile is different. An association on boot is fair and really OK. You 
are not really doing dhcp requests on boot and trying to get the 
internet from people for free. You just want you adapter running faster, 
get connected and get over whatever you have to do to start working or 
whatsoever.

Let's really think what would be the nicest way that the card should 
behave, after all if the adapter just associates, you are not really 
stealing any Internet. :)

Association on boot is how it has worked all the time, and in the 18 
months of the project, nobody has complained about it... So... I wonder, 
users are happy with it? (I know it might not be the correct way)

Just a thought.

.Alejandro

Re: ipw2100: firmware problem

[Jim Crilly]

On 06/09/05 09:30:22AM +0300, Denis Vlasenko wrote:
> On Thursday 09 June 2005 09:20, David S. Miller wrote:
> > From: Denis Vlasenko <vda@ilport.com.ua>
> > Date: Thu, 9 Jun 2005 09:17:23 +0300
> > 
> > > Sadly, realities are such that we have to live somehow
> > > with closed-source firmware.
> > 
> > You have a choice, buy products from friendly vendors.
> 
> I am trying! So far, I have Prism2.5, Prism54
> and acx111 cards, and all of them require closed binary fw.

Ralink cards don't require any binary firmware. I got one of the Hawking
Tech pcmcia cards off the shelf at a local CompUSA store and the card 
was a good $20 cheaper than a Linksys card. So far I haven't had any
problems with the card or the driver.

A list of Ralink hardware and drivers can be found at
http://ralink.rapla.net/ 

> vda
> 

Jim.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 17:31, Alejandro Bonilla wrote:
> 
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> >
> > That will be analogous to me plugging ethernet cable into the
> > switch and
> > wanting it to work, without any IP addr config, even without
> > DHCP client.
> > Just power up the box (or modprobe an eth module) and it
> > works! Cool, eh?
> >
> 
> You want things one way, I like them in another way. Whoever makes this
> decision should just know that we would like to have an option to make it
> load with or without the ASSOC on.

But you already _have_ the option to associate. Just issue
appropriate iwconfig command (or embed one in startup script).

> James already said to use the options ipw2100 disable=1 if you don't want it
> to associate everytime on boot.

Do we have to add such option to each and every wireless driver now?
That would be wrong since iwconfig already exists.

> At the end, who decides this?

User. As I said, with no automatic assoc at module load user still
may easily attain that with iwconfig.

Adding kernel level wireless autoconfiguration duplicates the effort.
Since I am not going to give up a requirement to be able to stay radio
silent at boot (me too wants freedom, not only you), you need to add
disable=1 module parameter to each driver, which adds to the mess.

ALSA does the Right Thing. Sound is completely muted out at module load.
It's a user freedom to set desired volume level after that.
--
vda

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> OK. I understand the point and I totally agree with this. We really want 
> the adapter to just do what the user or profiles ask the adapter to do. 
> Yes, in an ideal world.
> 
> Let's talk about easyness. These adapters are in laptops. You don't want 
> to type a lot of stop everytime you move from access points, reboots
> and 

We are not trying to make it hard to the users. Lets do the right
thing in kernel, and let userspace make it easy.
								Pavel

Re: ipw2100: firmware problem

[John Stoffel]

I'd like to chime in here and say that from my point of view, not
enabling the wireless network adaptor until asked by userspace is the
way to go. 

It reduces power requirements, and it pushes the configuration details
out to userspace, where they can be handled according to the policy
setup by the distro/user.

Having my latop bootup and turn on the wireless card and join an AP
without my explicity asking is a bad thing to have happen.  

John

RE: ipw2100: firmware problem

[Alejandro Bonilla]

>
> Adding kernel level wireless autoconfiguration duplicates the effort.
> Since I am not going to give up a requirement to be able to stay radio
> silent at boot (me too wants freedom, not only you), you need to add
> disable=1 module parameter to each driver, which adds to the mess.
>
> ALSA does the Right Thing. Sound is completely muted out at
> module load.
> It's a user freedom to set desired volume level after that.

Yeah right. I remember I had to google for 10 minutes to find the answer for
this one. Why would you install something, for it to not work?

It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
and enable it. Why would it make you google for more things to do? ALSA mute
on install is WAY way, not OK.

You *will* have to use a How-To with ALSA, nobody knows that your sound
would be off because some people decided it.

But this is out of the Topic. I agree with you all, but as I mentioned in a
more current email, this is a laptop, not a server. Things behave
differently and you want things faster. (Yes, I could have a script)

What I'm saying, is that just as ALSA, you will have to google even more
just to be able to look for the boot param for the driver for it to ASSOC on
boot like the Original drive does. Instead, if you simply don't want to
associate then turn off the Radio.

It's a simple FN+F2 or depends on your laptop.

Let's not make this a bigger thread, just decide and then do it that way.
I'm looking at this on the side of a supporter, seeing the emails from
users... "how do I make it behave as it was before" "it won't assoc on boot
anymore"

.Alejandro

> --
> vda
>

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> Hi!
> 
> > OK. I understand the point and I totally agree with this. 
> We really want 
> > the adapter to just do what the user or profiles ask the 
> adapter to do. 
> > Yes, in an ideal world.
> > 
> > Let's talk about easyness. These adapters are in laptops. 
> You don't want 
> > to type a lot of stop everytime you move from access points, reboots
> > and 
> 
> We are not trying to make it hard to the users. Lets do the right
> thing in kernel, and let userspace make it easy.
> 								Pavel

Pavel,

	Agreed then. 

RE: ipw2100: firmware problem

[Lee Revell]

On Fri, 2005-06-10 at 07:23 -0600, Alejandro Bonilla wrote:
> >
> > Adding kernel level wireless autoconfiguration duplicates the effort.
> > Since I am not going to give up a requirement to be able to stay radio
> > silent at boot (me too wants freedom, not only you), you need to add
> > disable=1 module parameter to each driver, which adds to the mess.
> >
> > ALSA does the Right Thing. Sound is completely muted out at
> > module load.
> > It's a user freedom to set desired volume level after that.
> 
> Yeah right. I remember I had to google for 10 minutes to find the answer for
> this one. Why would you install something, for it to not work?
> 
> It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
> and enable it. Why would it make you google for more things to do? ALSA mute
> on install is WAY way, not OK.

It took you 10 minutes of googling before you thought to try the mixer?
Sorry dude, this is PEBKAC.

Lee

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> > It thing of Mute in ALSA is stupid. If you want Sound, you
> install the Sound
> > and enable it. Why would it make you google for more things
> to do? ALSA mute
> > on install is WAY way, not OK.
>
> It took you 10 minutes of googling before you thought to try
> the mixer?
> Sorry dude, this is PEBKAC.
>
> Lee

Riiiight. It could be. Or it could be that no where in the world I have seen
something where the device would be disabled by default without notifying
the user. Why would you Mute the driver? Is the driver that bad, that the
developers would rather Mute the sound card, just in case if the sound cards
starts making noises and shit when the driver is loaded?

You are moving to another topic. Let's drop it.

.Alejandro

RE: ipw2100: firmware problem

[Lee Revell]

On Fri, 2005-06-10 at 15:00 -0600, Alejandro Bonilla wrote:
> > > It thing of Mute in ALSA is stupid. If you want Sound, you
> > install the Sound
> > > and enable it. Why would it make you google for more things
> > to do? ALSA mute
> > > on install is WAY way, not OK.
> >
> > It took you 10 minutes of googling before you thought to try
> > the mixer?
> > Sorry dude, this is PEBKAC.
> >
> > Lee
> 
> Riiiight. It could be. Or it could be that no where in the world I have seen
> something where the device would be disabled by default without notifying
> the user. Why would you Mute the driver? Is the driver that bad, that the
> developers would rather Mute the sound card, just in case if the sound cards
> starts making noises and shit when the driver is loaded?
> 

Userspace should handle it, doing this in the kernel is bloat.

My Debian system initializes the mixer settings to a sane state just
fine when the alsasound init script is run.  Maybe you need a better
distro.

Users who compile ALSA from source are expected to know what they are
doing.  And, if you watch the "make install" output, it prints a big fat
warning that all mixer controls are muted by default.

> You are moving to another topic. Let's drop it.

Agreed, but it was your OT rant that changed the topic...

Lee

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> > Riiiight. It could be. Or it could be that no where in the 
> world I have seen
> > something where the device would be disabled by default 
> without notifying
> > the user. Why would you Mute the driver? Is the driver that 
> bad, that the
> > developers would rather Mute the sound card, just in case 
> if the sound cards
> > starts making noises and shit when the driver is loaded?
> > 
> 
> Userspace should handle it, doing this in the kernel is bloat.

I Agreed to this since 8 AM.

> 
> My Debian system initializes the mixer settings to a sane state just
> fine when the alsasound init script is run.  Maybe you need a better
> distro.
I use Debian.
> 
> Users who compile ALSA from source are expected to know what they are
> doing.  And, if you watch the "make install" output, it 
> prints a big fat
> warning that all mixer controls are muted by default.

Who said I did it from source?

> 
> > You are moving to another topic. Let's drop it.
> 
> Agreed, but it was your OT rant that changed the topic...
> 
> Lee
dropped.
.Alejandro 

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Friday 10 June 2005 16:23, Alejandro Bonilla wrote:
> > Adding kernel level wireless autoconfiguration duplicates the effort.
> > Since I am not going to give up a requirement to be able to stay radio
> > silent at boot (me too wants freedom, not only you), you need to add
> > disable=1 module parameter to each driver, which adds to the mess.
> >
> > ALSA does the Right Thing. Sound is completely muted out at
> > module load.
> > It's a user freedom to set desired volume level after that.
> 
> Yeah right. I remember I had to google for 10 minutes to find the answer for
> this one. Why would you install something, for it to not work?
> 
> It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
> and enable it. Why would it make you google for more things to do? ALSA mute
> on install is WAY way, not OK.
> 
> You *will* have to use a How-To with ALSA, nobody knows that your sound
> would be off because some people decided it.

Well, which sound level shall be set instead? 100%? Maybe too loud for
my 500 watt loudpeakers, eh? 50%? Still too many. 5%? Nah.
My machine at work has a headphone which is anything but loud.
5% is nearly silence for it.

See? It's not a kernel matter at which volume sound must be set.
It is impossible to decide on the 'right' default.
 
> But this is out of the Topic. I agree with you all, but as I mentioned in a
> more current email, this is a laptop, not a server. Things behave
> differently and you want things faster. (Yes, I could have a script)

Or laptop oriented distro can have a script for you,
just like they already do have for DHCPizing all ifaces.

Not kernel business.

> What I'm saying, is that just as ALSA, you will have to google even more
> just to be able to look for the boot param for the driver for it to ASSOC on
> boot like the Original drive does. Instead, if you simply don't want to
> associate then turn off the Radio.
> 
> It's a simple FN+F2 or depends on your laptop.
> 
> Let's not make this a bigger thread, just decide and then do it that way.
> I'm looking at this on the side of a supporter, seeing the emails from
> users... "how do I make it behave as it was before" "it won't assoc on boot
> anymore"

Users which can not figure it by themself have not much power in dictating
how kernel drivers are written. Sure we listen to users, but we won't
blidly follow any and all suggestions.

If users want it different nodoby prohibits them from writing their own
drivers, right? Or patching existing ones, for that matter. Send patches to lkml
for discussion.
--
vda

Re: ipw2100: firmware problem

[Éric Brunet]

In ens.mailing-lists.linux-kernel, you wrote:
>
> I'm fighting with firmware problem: if ipw2100 is compiled into
> kernel, it is loaded while kernel boots and firmware loader is not yet
> available. That leads to uninitialized (=> useless) adapter.

By the way, can you get an ipw2100 working with suspend to ram ?

I have an ASUS s5200n with such a card. It is loaded with fedora core 2 
(stock kernel: kernel-2.6.10-1.12_FC2) + ipw2100 module and firmware
downloaded from atrpms.net (respectively
ipw2100-kmdl-2.6.10-1.12_FC2-1.0.0-27.1.rhfc2.at and
ipw2100-firmware-1.3-5.at).

Suspending to ram and resuming works very nicely, except that the wifi
card is dead till the next reboot. I tried to rmmod and modprobe the
ipw2100 module (either after the suspend/resume cycle, either rmmod before
suspend and modprobe after resume), but to no avail.

Looking at kernel messages to diagnose the problem, I also noticed a
couple of warnings.

Here are the messages happening during suspend/resume (cpufreq is
enabled):

##############################################################################
ehci_hcd 0000:00:1d.7: remove, state 1
usb usb1: USB disconnect, address 1
ehci_hcd 0000:00:1d.7: USB bus 1 deregistered
Stopping tasks: =================================================<6>Floppy drive(s): fd0 is 1.44M
==|
Back to C!
Warning: CPU frequency is 1400000, cpufreq assumed 600000 kHz.
Debug: sleeping function called from invalid context at mm/slab.c:2061
in_atomic():0, irqs_disabled():1
 [<c01188bb>] __might_sleep+0x80/0x8a
 [<c01488d9>] __kmalloc+0x40/0x76
 [<c01f20a5>] acpi_os_allocate+0xa/0xb
 [<c0205744>] acpi_ut_callocate+0x36/0x82
 [<c0205678>] acpi_ut_initialize_buffer+0x46/0x85
 [<c020263a>] acpi_rs_create_byte_stream+0x23/0x39
 [<c02039a6>] acpi_rs_set_srs_method_data+0x1b/0x9d
 [<c0116e26>] recalc_task_prio+0x128/0x133
 [<c020ae49>] acpi_pci_link_set+0xde/0x155
 [<c020b1cf>] irqrouter_resume+0x1c/0x30
 [<c0241bb7>] sysdev_resume+0x3e/0xc7
 [<c0244dea>] device_power_up+0x5/0xa
 [<c01398a2>] suspend_enter+0x25/0x2d
 [<c0139908>] enter_state+0x37/0x53
 [<c02084c2>] acpi_suspend+0x25/0x33
 [<c0208595>] acpi_system_write_sleep+0x5d/0x6e
 [<c0161bea>] vfs_write+0xb8/0xe4
 [<c0161cb4>] sys_write+0x3c/0x62
 [<c0103473>] syscall_call+0x7/0xb
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 7 (level, low) -> IRQ 7
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7
PCI: Setting latency timer of device 0000:00:1f.5 to 64
floppy0: no floppy controllers found
eth0: link down
ipw2100: eth1: ipw2100_verify failed: -5
ipw2100: eth1: Failed to power on the adapter.
ipw2100: eth1: Failed to start the firmware.
Restarting tasks... done
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 3 (level, low) -> IRQ 3
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 3, pci mem 0xfebff800
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
#####################################################################

Then, I did a  rmmod ipw2100

#####################################################################
divert: freeing divert_blk for eth1
#####################################################################

and I type ``ifup eth1'' to load it again:

#####################################################################
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.0
ipw2100: Copyright(c) 2003-2004 Intel Corporation
PCI: Enabling device 0000:01:05.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:01:05.0[A] -> GSI 7 (level, low) -> IRQ 7
PCI: Setting latency timer of device 0000:01:05.0 to 64
ipw2100Device not found via register read.
#####################################################################


For info, here are the boot messages:
#####################################################################
Linux version 2.6.10-1.12_FC2 (bhcompile@bugs.build.redhat.com) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 Wed Feb 2 01:13:49 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000f740000 (usable)
 BIOS-e820: 000000000f740000 - 000000000f750000 (ACPI data)
 BIOS-e820: 000000000f750000 - 000000000f800000 (ACPI NVS)
0MB HIGHMEM available.
247MB LOWMEM available.
On node 0 totalpages: 63296
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 59200 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM                                ) @ 0x000f4ff0
ACPI: RSDT (v001 A M I  OEMRSDT  0x02000427 MSFT 0x00000097) @ 0x0f740000
ACPI: FADT (v002 A M I  OEMFACP  0x02000427 MSFT 0x00000097) @ 0x0f740200
ACPI: MADT (v001 A M I  OEMAPIC  0x02000427 MSFT 0x00000097) @ 0x0f740300
ACPI: OEMB (v001 A M I  OEMBIOS  0x02000427 MSFT 0x00000097) @ 0x0f750040
ACPI: DSDT (v001  0ABBD 0ABBD001 0x00000001 MSFT 0x02000001) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
Built 1 zonelists
Kernel command line: ro root=LABEL=/ acpi_sleep=s3_bios
Initializing CPU#0
CPU 0 irqstacks, hard=c03e0000 soft=c03df000
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 600.231 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 246728k/253184k available (2064k kernel code, 5776k reserved, 684k data, 164k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1187.84 BogoMIPS (lpj=593920)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: a7e9fbbf 00000000 00000000 00000000
CPU: After vendor identify, caps:  a7e9fbbf 00000000 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 1024K
CPU: After all inits, caps:        a7e9f3bf 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel(R) Pentium(R) M processor 1400MHz stepping 05
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 00b8)
    ACPI-0077: *** Warning: Invalid FADT value PM_TM_LEN=3 at offset 5B FADT=cf73a840
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 201k freed
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: Embedded Controller [EC0] (gpe 28)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *4 5 6 7 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 12)
ACPI: Power Resource [GFAN] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1118513415.834:0): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 5C55E14F33E392D
- User ID: Red Hat, Inc. (Kernel Module GPG key)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Fan [FN00] (off)
ACPI: Processor [CPU1] (supports C1 C2 C3)
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: Thermal Zone [THRM] (30 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Maximum main memory to use for agp memory: 196M
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xf0000000
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 76 ports, IRQ sharing enabled
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
PCI: setting IRQ 7 as level-triggered
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 7 (level, low) -> IRQ 7
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
divert: not allocating divert_blk for non-ethernet device lo
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 7
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 7 (level, low) -> IRQ 7
ICH4: chipset revision 3
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: IC25N040ATMR04-0, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: max request size: 1024KiB
hda: 78140160 sectors (40007 MB) w/1740KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda4 < hda5 hda6 >
ide-floppy driver 0.99.newide
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
Synaptics Touchpad, model: 1
 Firmware: 5.9
 Sensor: 17
 new absolute packet format
 Touchpad has extended capability bits
 -> multifinger detection
 -> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio4
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 4681)
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI wakeup devices: 
P0P1 LAN0 CBS0 CBS1 P394 MPCI MODM USB1 USB2 USB3 EHCI SLPB 
ACPI: (supports S0 S1 S3 S4 S5)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 164k freed
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
ACPI: AC Adapter [AC0] (off-line)
Asus Laptop ACPI Extras version 0.29
  S5N model detected, supported
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Lid Switch [LID]
ibm_acpi: ec object not found
ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 3 (level, low) -> IRQ 3
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 3, pci mem 0xfebff800
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v2.2
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:1d.0: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 5, io base 0xd480
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 4
PCI: setting IRQ 4 as level-triggered
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 4 (level, low) -> IRQ 4
uhci_hcd 0000:00:1d.1: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 4, io base 0xd800
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 7 (level, low) -> IRQ 7
uhci_hcd 0000:00:1d.2: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 7, io base 0xd880
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
EXT3 FS on hda6, internal journal
device-mapper: 4.3.0-ioctl (2004-09-30) initialised: dm-devel@redhat.com
Adding 755012k swap on /dev/hda5.  Priority:-1 extents:1
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (1978 buckets, 15824 max) - 360 bytes per conntrack
8139too Fast Ethernet driver 0.9.27
ACPI: PCI interrupt 0000:01:04.0[A] -> GSI 5 (level, low) -> IRQ 5
divert: allocating divert_blk for eth0
eth0: RealTek RTL8139 at 0xc800, 00:0e:a6:b4:4a:cc, IRQ 5
eth0:  Identified 8139 chip type 'RTL-8101'
eth0: link down
ieee80211_crypt: registered algorithm 'NULL'
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.0
ipw2100: Copyright(c) 2003-2004 Intel Corporation
ACPI: PCI interrupt 0000:01:05.0[A] -> GSI 7 (level, low) -> IRQ 7
ipw2100: Detected Intel PRO/Wireless 2100 Network Connection
divert: allocating divert_blk for eth1
ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed.
ipw2100: eth1: ipw2100_get_firmware failed: -2
ipw2100: eth1: Failed to power on the adapter.
ipw2100: eth1: Failed to start the firmware.
divert: freeing divert_blk for eth1
ipw2100Error calling regiser_netdev.
ipw2100: probe of 0000:01:05.0 failed with error -5
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 7 (level, low) -> IRQ 7
Yenta: CardBus bridge found at 0000:01:03.0 [1043:1824]
Yenta: ISA IRQ mask 0x0400, PCI irq 7
Socket status: 30000006
ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) -> IRQ 7
Yenta: CardBus bridge found at 0000:01:03.1 [1043:1824]
Yenta: ISA IRQ mask 0x0400, PCI irq 7
Socket status: 30000006
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x377 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
lp: driver loaded but no devices found
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0375960(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.0
ipw2100: Copyright(c) 2003-2004 Intel Corporation
ACPI: PCI interrupt 0000:01:05.0[A] -> GSI 7 (level, low) -> IRQ 7
ipw2100: Detected Intel PRO/Wireless 2100 Network Connection
divert: allocating divert_blk for eth1
eth0: no IPv6 routers present
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 5 (level, low) -> IRQ 5
[drm] Initialized i830 1.3.2 20021108 on minor 0: 
[drm] Initialized i830 1.3.2 20021108 on minor 1: 
mtrr: base(0xf0020000) is not aligned on a size(0x300000) boundary
PCI: Enabling device 0000:00:1f.5 (0005 -> 0007)
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49451 usecs
intel8x0: clocking to 48000
eth0: link down
eth0: no IPv6 routers present
###########################################################################

Don't hesitate to ask for any further information.
Maybe upgrading to the forthcoming FC4 will help.

Éric Brunet

Re: ipw2100: firmware problem

[Zhu Yi]

On Sat, 2005-06-11 at 19:06 +0200, Éric Brunet wrote:
> By the way, can you get an ipw2100 working with suspend to ram ?

You can report a bug here:
http://bughost.org/bugzilla/

Thanks,
-yi

Re: ipw2100: firmware problem

[Jan Rychter]

>>>>> "Lee" == Lee Revell <rlrevell@joe-job.com> writes:
 Lee> On Fri, 2005-06-10 at 07:23 -0600, Alejandro Bonilla wrote:
 >> >
 >> > Adding kernel level wireless autoconfiguration duplicates the
 >> > effort.  Since I am not going to give up a requirement to be able
 >> > to stay radio silent at boot (me too wants freedom, not only you),
 >> > you need to add disable=1 module parameter to each driver, which
 >> > adds to the mess.
 >> >
 >> > ALSA does the Right Thing. Sound is completely muted out at module
 >> > load.  It's a user freedom to set desired volume level after that.
 >>
 >> Yeah right. I remember I had to google for 10 minutes to find the
 >> answer for this one. Why would you install something, for it to not
 >> work?
 >>
 >> It thing of Mute in ALSA is stupid. If you want Sound, you install
 >> the Sound and enable it. Why would it make you google for more
 >> things to do? ALSA mute on install is WAY way, not OK.

 Lee> It took you 10 minutes of googling before you thought to try the
 Lee> mixer?  Sorry dude, this is PEBKAC.

Oh, really, you think this works so well? Ever tried to use more than
one soundcard? A USB audio device? Ever wondered why oh why one has to
always check and twiddle with the mixers? Why (it seems) setting the
volume of USB audio devices via alsamixer doesn't work for apps which
use OSS emulation? Ever wondered why alsactl restore doesn't get called
by udev by default?

The current Linux approach (most distributions) is to let the user be
the master. Which means lots of typing, configuring, tweaking. Try that
on a tablet pc without a keyboard.

Things should Just Work. I wish most Linux developers tried using a Mac
at least once in their lifetimes.

--J.

Re: ipw2100: firmware problem

[Simon Kelley]

Jirka Bohac wrote:
> On Wed, Jun 08, 2005 at 05:44:20PM +0300, Denis Vlasenko wrote:
> 
>>On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
>>
>>>What's the prefered way to solve this one? Only load firmware when
>>>user does ifconfig eth1 up? [It is wifi, it looks like it would be
>>>better to start firmware sooner so that it can associate to the
>>>AP...].
>>
>>Do you want to associate to an AP when your kernel boots,
>>_before_ any iwconfig had a chance to configure anything?
>>That's strange.
>>
>>My position is that wifi drivers must start up in an "OFF" mode.
>>Do not send anything. Do not join APs or start IBSS.
> 
> 
> Agreed.
> 
> 
>>Thus, no need to load fw in early boot.
> 
> 
> I don't think this is true. Loading the firmware on the first
> "ifconfig up" is problematic. Often, people want to rename the
> device from ethX/wlanX/... to something stable. This is usually
> based on the adapter's MAC address, which is not visible until
> the firmware is loaded.
> 
> Prism54 does it this way and it really sucks. You need to bring
> the adapter up to load the firmware, then bring it back down,
> rename it, and bring it up again.
> 

The atmel driver includes a small firmware stub which does nothing but 
determine the MAC address, to solve this problem. This is compiled into 
the driver and so doesn't depend on request_firmware(). The stub was 
created by reverse engineering the card and is GPL, so there's no 
problem including it in the kernel.

This is not a general solution, since it depends on the ability to 
create such MAC reader firmware, but it might be a possibility in this case.


Cheers,

Simon.

Re: ipw2100: firmware problem

[Feyd]

On Tue, 21 Jun 2005 08:42:08 +0100
Simon Kelley <simon@thekelleys.org.uk> wrote:

> The atmel driver includes a small firmware stub which does nothing but 
> determine the MAC address, to solve this problem. This is compiled into 

Does it power-down the card after reading the MAC?

Feyd

Re: ipw2100: firmware problem

[Simon Kelley]

Feyd wrote:
> On Tue, 21 Jun 2005 08:42:08 +0100
> Simon Kelley <simon@thekelleys.org.uk> wrote:
> 
> 
>>The atmel driver includes a small firmware stub which does nothing but 
>>determine the MAC address, to solve this problem. This is compiled into 
> 
> 
> Does it power-down the card after reading the MAC?
> 

Yes, it loads the special firmware, runs it to get the MAC, and then 
returns the card to quiesent state, ready for the real firmware load 
which happens at device open time.

Cheers,

Simon.