Request for help...

Request for help...

[Axj]

Hi, I'm alex....

I have a notebook Acer Aspire 5920G, with an intel 4965 wireless, system is a Slackware 12 and kernel is my personal recompiled version of 2.6.21.5. 

Usually I use the drivers of the version 0.0.* with macsubsystem version 8.0.2, but I've tried to compile the version 0.1.2... a lot of compilation problem. So I think to use  mac9.0.2..... 
after the make modules of these it's arrived this message.... 


net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_add':
net/mac80211/wme.c:759: error: dereferencing pointer to incomplete type
net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_remove':
net/mac80211/wme.c:784: error: dereferencing pointer to incomplete type
make[2]: *** [net/mac80211/wme.o] Error 1
make[1]: *** [net/mac80211] Error 2
make: *** [net] Error 2


so I can't compile the new version, but, even if the compilation is not finished, when I retried to compile iwl version 0.1.2, it works. Now for me is impossible to  understand, and I'm tring the way to make mac802 subsys work. Can anyone help me....

Another little question... exist a way for make work the wireless led that is always off, even if the wireless works.

Sorry for the request and for the the bad english... it's a lot of time that I don't wrote to a english mailing list (the last was alsa).

Tank you 
Alex

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2

Re: Request for help...

[John W. Linville]

Since Intel continues to develop their mac80211 fork
on their own, you will have to seek support from them at
ipw3945-devel@lists.sourceforge.net.

I keep hearing that Intel intends to come back to working with the
community on mac80211.  Alas, that has yet to happen.  I want to
believe that it will soon...?

John

On Tue, Jul 24, 2007 at 08:02:12AM -0700, Axj wrote:
> Hi, I'm alex....
> 
> I have a notebook Acer Aspire 5920G, with an intel 4965 wireless, system is a Slackware 12 and kernel is my personal recompiled version of 2.6.21.5. 
> 
> Usually I use the drivers of the version 0.0.* with macsubsystem version 8.0.2, but I've tried to compile the version 0.1.2... a lot of compilation problem. So I think to use  mac9.0.2..... 
> after the make modules of these it's arrived this message.... 
> 
> 
> net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_add':
> net/mac80211/wme.c:759: error: dereferencing pointer to incomplete type
> net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_remove':
> net/mac80211/wme.c:784: error: dereferencing pointer to incomplete type
> make[2]: *** [net/mac80211/wme.o] Error 1
> make[1]: *** [net/mac80211] Error 2
> make: *** [net] Error 2
> 
> 
> so I can't compile the new version, but, even if the compilation is not finished, when I retried to compile iwl version 0.1.2, it works. Now for me is impossible to  understand, and I'm tring the way to make mac802 subsys work. Can anyone help me....
> 
> Another little question... exist a way for make work the wireless led that is always off, even if the wireless works.
> 
> Sorry for the request and for the the bad english... it's a lot of time that I don't wrote to a english mailing list (the last was alsa).
> 
> Tank you 
> Alex
> 
> ----------------------------------------------------------------------
> Get a free email account with anti spam protection.
> http://www.bluebottle.com/tag/2
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] Request for help...

[Stephen Clark]

Hi John,

Just being a user I am not sure what you mean by come back to working 
with community? None of
their stuff is hidden is it? Does "the community" make it so hard to get 
stuff included that it is
not worth the pain for Intel?

Just wondering.

Steve

John W. Linville wrote:

>Since Intel continues to develop their mac80211 fork
>on their own, you will have to seek support from them at
>ipw3945-devel@lists.sourceforge.net.
>
>I keep hearing that Intel intends to come back to working with the
>community on mac80211.  Alas, that has yet to happen.  I want to
>believe that it will soon...?
>
>John
>
>On Tue, Jul 24, 2007 at 08:02:12AM -0700, Axj wrote:
>  
>
>>Hi, I'm alex....
>>
>>I have a notebook Acer Aspire 5920G, with an intel 4965 wireless, system is a Slackware 12 and kernel is my personal recompiled version of 2.6.21.5. 
>>
>>Usually I use the drivers of the version 0.0.* with macsubsystem version 8.0.2, but I've tried to compile the version 0.1.2... a lot of compilation problem. So I think to use  mac9.0.2..... 
>>after the make modules of these it's arrived this message.... 
>>
>>
>>net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_add':
>>net/mac80211/wme.c:759: error: dereferencing pointer to incomplete type
>>net/mac80211/wme.c: In function 'ieee80211_ht_agg_queue_remove':
>>net/mac80211/wme.c:784: error: dereferencing pointer to incomplete type
>>make[2]: *** [net/mac80211/wme.o] Error 1
>>make[1]: *** [net/mac80211] Error 2
>>make: *** [net] Error 2
>>
>>
>>so I can't compile the new version, but, even if the compilation is not finished, when I retried to compile iwl version 0.1.2, it works. Now for me is impossible to  understand, and I'm tring the way to make mac802 subsys work. Can anyone help me....
>>
>>Another little question... exist a way for make work the wireless led that is always off, even if the wireless works.
>>
>>Sorry for the request and for the the bad english... it's a lot of time that I don't wrote to a english mailing list (the last was alsa).
>>
>>Tank you 
>>Alex
>>
>>----------------------------------------------------------------------
>>Get a free email account with anti spam protection.
>>http://www.bluebottle.com/tag/2
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>    
>>
>
>  
>


-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

Re: [ipw3945-devel] Request for help...

[John W. Linville]

On Tue, Jul 24, 2007 at 02:29:23PM -0400, Stephen Clark wrote:

> Just being a user I am not sure what you mean by come back to working 
> with community? None of
> their stuff is hidden is it? Does "the community" make it so hard to get 
> stuff included that it is
> not worth the pain for Intel?

Very simple -- conduct mac80211 development in public on a mailing
list appropriate to discussion of an in-kernel component rather than
hiding on a mailing list that is ostensibly for development of a
specific driver.  As the authors of the patches it is incumbent on
Intel to post them for inclusion upstream.  That is the price of good
citizenship in the Linux community.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

John W. Linville wrote:
> On Tue, Jul 24, 2007 at 02:29:23PM -0400, Stephen Clark wrote:
> 
>> Just being a user I am not sure what you mean by come back to working 
>> with community? None of
>> their stuff is hidden is it? Does "the community" make it so hard to get 
>> stuff included that it is
>> not worth the pain for Intel?
> 
> Very simple -- conduct mac80211 development in public on a mailing
> list appropriate to discussion of an in-kernel component rather than
> hiding on a mailing list that is ostensibly for development of a
> specific driver.  As the authors of the patches it is incumbent on
> Intel to post them for inclusion upstream.  That is the price of good
> citizenship in the Linux community.

Not just that... it's good engineering.

Wireless driver patches that don't make it rapidly to linux-wireless and 
upstream rapidly fester.  It becomes a real engineering challenge to 
sync up with upstream, if you don't make that your primary task to begin 
with.

There is a reason why we say "release early, release often."  If 
wireless developers don't hear from Intel on a regular basis, the 
codebases will diverge, wireless hackers will not get the useful 
feedback they need, and Intel hackers will not get the useful feedback 
they need.

Open source isn't just about a source code license.  This is an 
-engineering process-.  Post -> [merge | revise based on feedback ] -> 
<infinity>.  The lower the frequency of posting and community 
interaction, the less you are actually participating in key portions of 
the engineering process.

	Jeff

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

James Ketrenos wrote:
> Jeff Garzik wrote:
> 
>> There is a reason why we say "release early, release often."  If 
>> wireless developers don't hear from Intel on a regular basis,
> 
> The "community" vs. "Intel" slant is really getting old. 
> *WE* are part of the community.  *WE* have submitted patches.  *WE* have 
> done work to bring wireless forward.  *WE* are wireless developers.
> 
> It isn't Intel's fault that certain people have historically made it so 
> difficult to get code to into wireless-dev's mac80211 (and eventually 
> *maybe* upstream) that contributors have decided to focus on getting 
> their code out to users through other means.
> 
> A version of mac80211 being available out-of-tree with features not 
> found in wireless-dev isn't the problem.  The problem is that people 
> have made it too difficult to innovate and develop in wireless-dev.

Well, the facts according to my search are:

* last iwlwifi submit was almost two months ago, in a form difficult to 
review and discuss on the mailing list, save for a bug fix.  And I note, 
the submission went into wireless-dev rapidly.

* last mac80211 patches were almost three months ago, save for two small 
add-ioctl patches from Mohamed and Hong.

* no one else seems to have the same trouble getting patches in

Whereas other developers are actively posting patches, big and small, to 
linux-wireless on a regular basis.  I just don't see much activity at 
all on {linux-kernel,linux-wireless,netdev} from Intel with regards to 
the new wireless.

Intel is the only wireless driver developer doing development 
"elsewhere", rather than where the wireless hackers hang out.  Even 
assuming a hypothetical worst case of 100% patch drops, you should be 
working and posting where other developers are also working and posting. 
  That is just a BASIC part of the open source kernel engineering process.

Another key part of open source is "release early, release often" so 
that people are aware of your work and needs, and can provide rapid 
feedback.  That means posting most patches to linux-wireless as soon as 
they work on your basic quick-test setup.  Intel is definitely not 
"releasing early and often" from the LKML perspective.

Though in fairness, I am a bit disappointed that wireless-dev seems to 
occasionally become a resting place for drivers, rather than just a pit 
stop on the way to upstream.  In particular, stuff still has not been 
moved out of drivers/net/wireless/mac80211 and into 
drivers/net/wireless, which is a basic and easy step to get all code 
ready for upstream.

	Jeff

Re: [ipw3945-devel] Request for help...

[Stephen Clark]

Jeff Garzik wrote:

>James Ketrenos wrote:
>  
>
>>Jeff Garzik wrote:
>>
>>    
>>
>>>There is a reason why we say "release early, release often."  If 
>>>wireless developers don't hear from Intel on a regular basis,
>>>      
>>>
>>The "community" vs. "Intel" slant is really getting old. 
>>*WE* are part of the community.  *WE* have submitted patches.  *WE* have 
>>done work to bring wireless forward.  *WE* are wireless developers.
>>
>>It isn't Intel's fault that certain people have historically made it so 
>>difficult to get code to into wireless-dev's mac80211 (and eventually 
>>*maybe* upstream) that contributors have decided to focus on getting 
>>their code out to users through other means.
>>
>>A version of mac80211 being available out-of-tree with features not 
>>found in wireless-dev isn't the problem.  The problem is that people 
>>have made it too difficult to innovate and develop in wireless-dev.
>>    
>>
>
>Well, the facts according to my search are:
>
>* last iwlwifi submit was almost two months ago, in a form difficult to 
>review and discuss on the mailing list, save for a bug fix.  And I note, 
>the submission went into wireless-dev rapidly.
>
>* last mac80211 patches were almost three months ago, save for two small 
>add-ioctl patches from Mohamed and Hong.
>
>* no one else seems to have the same trouble getting patches in
>
>Whereas other developers are actively posting patches, big and small, to 
>linux-wireless on a regular basis.  I just don't see much activity at 
>all on {linux-kernel,linux-wireless,netdev} from Intel with regards to 
>the new wireless.
>
>Intel is the only wireless driver developer doing development 
>"elsewhere", rather than where the wireless hackers hang out.  Even 
>assuming a hypothetical worst case of 100% patch drops, you should be 
>working and posting where other developers are also working and posting. 
>  That is just a BASIC part of the open source kernel engineering process.
>
>Another key part of open source is "release early, release often" so 
>that people are aware of your work and needs, and can provide rapid 
>feedback.  That means posting most patches to linux-wireless as soon as 
>they work on your basic quick-test setup.  Intel is definitely not 
>"releasing early and often" from the LKML perspective.
>
>Though in fairness, I am a bit disappointed that wireless-dev seems to 
>occasionally become a resting place for drivers, rather than just a pit 
>stop on the way to upstream.  In particular, stuff still has not been 
>moved out of drivers/net/wireless/mac80211 and into 
>drivers/net/wireless, which is a basic and easy step to get all code 
>ready for upstream.
>
>	Jeff
>
>
>  
>
I find it really sad that a hardware vendor that is willing to write and develope drivers for Linux for their hardware aren't helped more by "the community" or is the "the community" only interested in hacking drivers where the manufacturer give no or minimal support?

I appreciate Intel's support for being open and purposely bought a laptop that had an Intel graphics chipset and an Intel wireless card.

My $.02
Steve
"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

Re: [ipw3945-devel] Request for help...

[David Miller]

From: Stephen Clark <Stephen.Clark@seclark.us>
Date: Tue, 24 Jul 2007 20:30:16 -0400

> I find it really sad that a hardware vendor that is willing to write
> and develope drivers for Linux for their hardware aren't helped more
> by "the community" or is the "the community" only interested in
> hacking drivers where the manufacturer give no or minimal support?

This is a massive mischaracterization of reality.

I agree with every statement Jeff has made, Intel really is a problem
child in this area, and consistently so.

The only way we could "help them" more is to take over the code base
and do the development for them.

The thing you should find truly sad is how Intel handles these
situations time and time again, rather than the tireless attempts of
Jeff and others to education them on how to improve the situation.

Re: [ipw3945-devel] Request for help...

[Stephen Clark]

David Miller wrote:

>From: Stephen Clark <Stephen.Clark@seclark.us>
>Date: Tue, 24 Jul 2007 20:30:16 -0400
>
>  
>
>>I find it really sad that a hardware vendor that is willing to write
>>and develope drivers for Linux for their hardware aren't helped more
>>by "the community" or is the "the community" only interested in
>>hacking drivers where the manufacturer give no or minimal support?
>>    
>>
>
>This is a massive mischaracterization of reality.
>
>I agree with every statement Jeff has made, Intel really is a problem
>child in this area, and consistently so.
>
>The only way we could "help them" more is to take over the code base
>and do the development for them.
>
>The thing you should find truly sad is how Intel handles these
>situations time and time again, rather than the tireless attempts of
>Jeff and others to education them on how to improve the situation.
>
>  
>
So if someone in "the community" really wanted to help  Intel why don't 
they take the
code Intel posts to  the ipw3945 ml and put it into where ever it is 
really supposed to go?
Instead of whining how Intel doesn't do it right.



-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

Re: [ipw3945-devel] Request for help...

[Maurizio Monge]

I agree with Stephen, and i purchased a laptop with intel
graphics/wireless for exactly the same reason too.
Now i really hope that this thread instead of continuing as a flamewar
will positively help intel developer to have better interactions with
wireless-dev people, as it would be in the best interest for both.

My =80.02 (but note that they are =80 and not $ :) )

On 7/25/07, Stephen Clark <Stephen.Clark@seclark.us> wrote:
> Jeff Garzik wrote:
>
> >James Ketrenos wrote:
> >
> >
> >>Jeff Garzik wrote:
> >>
> >>
> >>
> >>>There is a reason why we say "release early, release often."  If
> >>>wireless developers don't hear from Intel on a regular basis,
> >>>
> >>>
> >>The "community" vs. "Intel" slant is really getting old.
> >>*WE* are part of the community.  *WE* have submitted patches.  *WE*=
 have
> >>done work to bring wireless forward.  *WE* are wireless developers.
> >>
> >>It isn't Intel's fault that certain people have historically made i=
t so
> >>difficult to get code to into wireless-dev's mac80211 (and eventual=
ly
> >>*maybe* upstream) that contributors have decided to focus on gettin=
g
> >>their code out to users through other means.
> >>
> >>A version of mac80211 being available out-of-tree with features not
> >>found in wireless-dev isn't the problem.  The problem is that peopl=
e
> >>have made it too difficult to innovate and develop in wireless-dev.
> >>
> >>
> >
> >Well, the facts according to my search are:
> >
> >* last iwlwifi submit was almost two months ago, in a form difficult=
 to
> >review and discuss on the mailing list, save for a bug fix.  And I n=
ote,
> >the submission went into wireless-dev rapidly.
> >
> >* last mac80211 patches were almost three months ago, save for two s=
mall
> >add-ioctl patches from Mohamed and Hong.
> >
> >* no one else seems to have the same trouble getting patches in
> >
> >Whereas other developers are actively posting patches, big and small=
, to
> >linux-wireless on a regular basis.  I just don't see much activity a=
t
> >all on {linux-kernel,linux-wireless,netdev} from Intel with regards =
to
> >the new wireless.
> >
> >Intel is the only wireless driver developer doing development
> >"elsewhere", rather than where the wireless hackers hang out.  Even
> >assuming a hypothetical worst case of 100% patch drops, you should b=
e
> >working and posting where other developers are also working and post=
ing.
> >  That is just a BASIC part of the open source kernel engineering pr=
ocess.
> >
> >Another key part of open source is "release early, release often" so
> >that people are aware of your work and needs, and can provide rapid
> >feedback.  That means posting most patches to linux-wireless as soon=
 as
> >they work on your basic quick-test setup.  Intel is definitely not
> >"releasing early and often" from the LKML perspective.
> >
> >Though in fairness, I am a bit disappointed that wireless-dev seems =
to
> >occasionally become a resting place for drivers, rather than just a =
pit
> >stop on the way to upstream.  In particular, stuff still has not bee=
n
> >moved out of drivers/net/wireless/mac80211 and into
> >drivers/net/wireless, which is a basic and easy step to get all code
> >ready for upstream.
> >
> >       Jeff
> >
> >
> >
> >
> I find it really sad that a hardware vendor that is willing to write =
and develope drivers for Linux for their hardware aren't helped more by=
 "the community" or is the "the community" only interested in hacking d=
rivers where the manufacturer give no or minimal support?
>
> I appreciate Intel's support for being open and purposely bought a la=
ptop that had an Intel graphics chipset and an Intel wireless card.
>
> My $.02
> Steve
> "They that give up essential liberty to obtain temporary safety,
> deserve neither liberty nor safety."  (Ben Franklin)
>
> "The course of history shows that as a government grows, liberty
> decreases."  (Thomas Jefferson)
>
>
>
>
> ---------------------------------------------------------------------=
----
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browse=
r.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Ipw3945-devel mailing list
> Ipw3945-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>


--=20
Ciao
Maurizio
http://stregatto.wordpress.com

"Well we all shine on
Like the moon and the stars and the sun" (John Lennon)
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] Request for help...

[David Miller]

From: Stephen Clark <Stephen.Clark@seclark.us>
Date: Tue, 24 Jul 2007 20:43:13 -0400

> So if someone in "the community" really wanted to help Intel why
> don't they take the code Intel posts to the ipw3945 ml and put it
> into where ever it is really supposed to go?

Because it's better to teach someone how to fish than to continually
fish for them.

Re: [ipw3945-devel] Request for help...

[Stephen Clark]

David Miller wrote:

>From: Stephen Clark <Stephen.Clark@seclark.us>
>Date: Tue, 24 Jul 2007 20:43:13 -0400
>
>  
>
>>So if someone in "the community" really wanted to help Intel why
>>don't they take the code Intel posts to the ipw3945 ml and put it
>>into where ever it is really supposed to go?
>>    
>>
>
>Because it's better to teach someone how to fish than to continually
>fish for them.
>
>  
>
David,

I understand what you are saying on one hand, but you are also saying 
that Intel
is by themselves and no one in the community is going to help, if Intel 
can't figure
out how to do it the right way.
What I am saying why can't someone in the community be a liason
between what Intel is doing and wireless-dev? Why does it have to be 
someone from
Intel?


-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

Re: [ipw3945-devel] Request for help...

[James Ketrenos]

Jeff Garzik wrote:

> There is a reason why we say "release early, release often."  If 
> wireless developers don't hear from Intel on a regular basis,

The "community" vs. "Intel" slant is really getting old.  

*WE* are part of the community.  *WE* have submitted patches.  
*WE* have done work to bring wireless forward.  *WE* are wireless 
developers.

It isn't Intel's fault that certain people have historically 
made it so difficult to get code to into wireless-dev's mac80211 
(and eventually *maybe* upstream) that contributors have decided 
to focus on getting their code out to users through other means.

A version of mac80211 being available out-of-tree with features 
not found in wireless-dev isn't the problem.  The problem is that 
people have made it too difficult to innovate and develop in 
wireless-dev.

*That* needs to change.

James

Re: [ipw3945-devel] Request for help...

[David Miller]

From: Stephen Clark <Stephen.Clark@seclark.us>
Date: Tue, 24 Jul 2007 21:05:59 -0400

[ ipw3945-devel removed from CC: as it's subscriber only ]

> I understand what you are saying on one hand, but you are also
> saying that Intel is by themselves and no one in the community is
> going to help, if Intel can't figure out how to do it the right way.

The Intel developers are not a bunch of neophytes who need their hands
held in this kind of situation, stop making it seem this way.

It doesn't take a genius nor an enormous amount of effort to post
one's work on the appropriate mailing list, in a timely and
appropriate manner.

What Intel is doing is hurting users just like you, whether you choose
to see that or not.

Again, you are massively mischaracterizing the situation, and this has
the potential to mislead people, so I will sit here for days and
refute you if that is what it takes.

Jeff should be applauded, instead of put down, for his endless
patience with Intel and the effort he puts forth to educate them.

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

Stephen Clark wrote:
> I understand what you are saying on one hand, but you are also saying 
> that Intel
> is by themselves and no one in the community is going to help, if Intel 
> can't figure
> out how to do it the right way.

David referenced "the tireless attempts of Jeff and others to education 
them on how to improve the situation"


> What I am saying why can't someone in the community be a liason
> between what Intel is doing and wireless-dev? Why does it have to be 
> someone from
> Intel?

Ideally it is the hardware vendor that maintains their own Linux drivers 
in the upstream kernel.  That is the ideal.  It scales best and focuses 
knowledge and resources in everyone's best interests.

To answer your question, it does not HAVE to be somebody at Intel.  On 
occasion, when a hardware vendor was exceedingly difficult to work with, 
someone in the community will step up and fill that gap.

The problem with such a liaison is that they must maintain a fork of the 
vendor driver themselves, which is time consuming and annoying, because 
you wind up buffering the code and problem complaints from the community 
as well as trying to reconcile that with new vendor driver engineering.

That process, as we saw with skge and tg3 drivers, usually ends up with 
the community maintaining a driver independent of the hardware vendor, 
using the hardware vendor's driver purely as a reference manual, once 
things are out-of-sync enough.  That's not generally a situation the 
hardware vendor likes, since they lose a lot of control -- though in 
tg3's case, the driver quality and upstream incentives were such that 
the vendor switched from their own driver to tg3.  And now the tg3 
vendor is back in control, actively submitting patches, and overall 
being an excellent example of open source engineering done right.

In general, most incentives rest on Intel to get stuff upstream.  That's 
where the process is most efficient, and all involved (Linux users, 
Kernel hackers, and Intel) benefit.

Part of my tireless work is _not_ throwing my hands up in frustration 
and doing it all myself :) but instead trying to counsel on where the 
process is getting stuck.

	Jeff

Re: [ipw3945-devel] Request for help...

[Stephen Clark]

Jeff Garzik wrote:

>Stephen Clark wrote:
>  
>
>>I understand what you are saying on one hand, but you are also saying 
>>that Intel
>>is by themselves and no one in the community is going to help, if Intel 
>>can't figure
>>out how to do it the right way.
>>    
>>
>
>David referenced "the tireless attempts of Jeff and others to education 
>them on how to improve the situation"
>
>
>  
>
>>What I am saying why can't someone in the community be a liason
>>between what Intel is doing and wireless-dev? Why does it have to be 
>>someone from
>>Intel?
>>    
>>
>
>Ideally it is the hardware vendor that maintains their own Linux drivers 
>in the upstream kernel.  That is the ideal.  It scales best and focuses 
>knowledge and resources in everyone's best interests.
>
>To answer your question, it does not HAVE to be somebody at Intel.  On 
>occasion, when a hardware vendor was exceedingly difficult to work with, 
>someone in the community will step up and fill that gap.
>
>The problem with such a liaison is that they must maintain a fork of the 
>vendor driver themselves, which is time consuming and annoying, because 
>you wind up buffering the code and problem complaints from the community 
>as well as trying to reconcile that with new vendor driver engineering.
>
>That process, as we saw with skge and tg3 drivers, usually ends up with 
>the community maintaining a driver independent of the hardware vendor, 
>using the hardware vendor's driver purely as a reference manual, once 
>things are out-of-sync enough.  That's not generally a situation the 
>hardware vendor likes, since they lose a lot of control -- though in 
>tg3's case, the driver quality and upstream incentives were such that 
>the vendor switched from their own driver to tg3.  And now the tg3 
>vendor is back in control, actively submitting patches, and overall 
>being an excellent example of open source engineering done right.
>
>In general, most incentives rest on Intel to get stuff upstream.  That's 
>where the process is most efficient, and all involved (Linux users, 
>Kernel hackers, and Intel) benefit.
>
>Part of my tireless work is _not_ throwing my hands up in frustration 
>and doing it all myself :) but instead trying to counsel on where the 
>process is getting stuck.
>
>	Jeff
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>
Jeff,

Thanks for all you do and taking the time to explain what probably was 
apparent
already to a lot of people.

Steve

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

Stephen Clark wrote:
> I find it really sad that a hardware vendor that is willing to write and 
> develope drivers for Linux for their hardware aren't helped more by "the 
> community"

It's hard to be more helpful without (a) explaining the problems with 
the current situation and suggesting corrections, or (b) doing it all 
myself.


> or is the "the community" only interested in hacking drivers where
> the manufacturer give no or minimal support?

The more people working on drivers, the wider the workload is spread, 
which is a good thing.

The caveat being you cannot just throw any old crap into the kernel, 
just because you are a Big Hardware Vendor.  Linux thrives precisely 
because of the system of engineering review and Internet-scale testing 
that we have set up.

We have an engineering process that has proven itself over the past 10+ 
years.  You don't just chuck that out the window because someone doesn't 
want to follow the process.  Making exceptions for Big Vendors who can't 
grok the rules is not how Linux became successful.

These processes all have carefully considered engineering rationale 
behind them.  The obvious engineering breakdowns occur when you avoid 
the standard process...  the process that has been delivering stable 
hardware support to you and other Linux users.


> I appreciate Intel's support for being open and purposely bought a 
> laptop that had an Intel graphics chipset and an Intel wireless card.

Intel gets five stars in the areas of open source CPU, platform, and 
graphics support.  Intel graphics is really going to kick ass (not that 
it doesn't already), and Keith Packard (old-school X11 hacker) is 
leading the charge.  And Intel networking definitely gets applause for 
doing open source networking as well.

But we just don't shove any old vendor driver into the kernel.  Not when 
we have to maintain these drivers for a decade, often after the vendor 
themselves end-of-life's the chip.

	Jeff

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

Stephen Clark wrote:
> So if someone in "the community" really wanted to help  Intel why don't 
> they take the
> code Intel posts to  the ipw3945 ml and put it into where ever it is 
> really supposed to go?
> Instead of whining how Intel doesn't do it right.


Unscalable.

People in the past sometimes asked Linus, "why didn't you go to $foo.com 
website and download the patches?  they work for me!"  Same reason: 
it's unscalable.

For each step in the maintainership pyramid of trust, the number of 
people at that level decreases from the previous step.  Patches trickle 
-up- from sub-maintainers to maintainers to Andrew and finally Linus.

Thus, it is unreasonable for a kernel maintainer to poll $N mailing 
lists, coalesce the opinion, grok the code, make sure the code is at a 
point where it is OK to push upstream, and then push.  That's a 
one-to-many operation.

In contrast, a WORKING example of kernel development is a many-to-one 
process.  Driver maintainers send patches to subsystem maintainers. 
Subsystem maintainers send patches to higher-level subsystem 
maintainers.  High-level subsystem maintainers send patches to Andrew 
and Linus.

That's scalable.

	Jeff

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

David Miller wrote:
> From: Stephen Clark <Stephen.Clark@seclark.us>
> Date: Tue, 24 Jul 2007 20:43:13 -0400
> 
>> So if someone in "the community" really wanted to help Intel why
>> don't they take the code Intel posts to the ipw3945 ml and put it
>> into where ever it is really supposed to go?
> 
> Because it's better to teach someone how to fish than to continually
> fish for them.

Yep.  Less work for you and me, too, that way :)

Win-win.  :)

	Jeff

Re: [ipw3945-devel] Request for help...

[James Ketrenos]

Jeff Garzik wrote:

> Intel is definitely not releasing early and often" from the LKML perspective.

I agree the cadence to >>linux-wireless<< has been lacking.  But Intel
is releasing early and often.  You can check their GIT logs and snapshot
history as evidence of that.

I am very hopeful that the people working on the 802.11n and HT patches, 
as well as the developers working on the iwlwifi drivers, will get their
patches together and submitted to linux-wireless for inclusion.  

I am also hopeful that those patches will be evaluated on the merit and
value of the functionality they enable.  

<soapbox>

If people on linux-wireless don't want contributors to go off and 
spend weeks / months at a time working in another sandbox, on another 
mailing list, or in a different development community, maybe the 
general attitude and approach of the maintainers on linux-wireless 
needs to be one which facilitates those individual's contributions, 
and helps in encouraging them to do more in the future.  Even if those
contributors work for a Big Hardware Vendor.

Working with a community should augment development, not complicate 
it or become a burden to it.  People should feel better about their 
contributions after engaging in a thread in a community where one 
of their patches is reviewed; they should feel like progress has been
made, their contributions have been shared, and now others can benefit
from them -- they should not walk away feeling demoralized and berated
for trying.

More often than not, my time on linux-wireless has left me feeling 
like the later.

<soapbox/>

James

Re: Request for help...

[Zhu Yi]

On Tue, 2007-07-24 at 08:02 -0700, Axj wrote:
> so I can't compile the new version, but, even if the compilation is
> not finished, when I retried to compile iwl version 0.1.2, it works.
> Now for me is impossible to  understand, and I'm tring the way to make
> mac802 subsys work. Can anyone help me....

iwlwifi-0.1.3 fixed this problem.

Thanks,
-yi

Re: [ipw3945-devel] Request for help...

[John W. Linville]

On Tue, Jul 24, 2007 at 08:03:37PM -0400, Jeff Garzik wrote:

> Though in fairness, I am a bit disappointed that wireless-dev seems to 
> occasionally become a resting place for drivers, rather than just a pit 
> stop on the way to upstream.  In particular, stuff still has not been 
> moved out of drivers/net/wireless/mac80211 and into 
> drivers/net/wireless, which is a basic and easy step to get all code 
> ready for upstream.

Point taken.  I'll apply a series of patches to eliminate the extra
directory.  I guess I'll rename the existing bcm43xx and zd1211rw
drivers in wireless-dev as a temporary measure until those ports are
done upstream.

I would definitely like to see more action from mac80211 driver
developers towards getting drivers upstream.  With mac80211 merged,
I know of no reason not to get the drivers ready for upstream now so
they can funnel through netdev-2.6 into -mm with plenty of time to
spare before the next merge window.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] Request for help...

[John W. Linville]

On Wed, Jul 25, 2007 at 01:01:16AM -0700, James Ketrenos wrote:

> Working with a community should augment development, not complicate 
> it or become a burden to it.  People should feel better about their 
> contributions after engaging in a thread in a community where one 
> of their patches is reviewed; they should feel like progress has been
> made, their contributions have been shared, and now others can benefit
> from them -- they should not walk away feeling demoralized and berated
> for trying.

I agree with this in principle.  After discussions with many of the
developers involved, I am optimistic that the next round of reviews
will be handled more gracefully.  The important part now is to get
those patches flowing back to linux-wireless so we can get the process
working again.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

John W. Linville wrote:
> I would definitely like to see more action from mac80211 driver
> developers towards getting drivers upstream.  With mac80211 merged,
> I know of no reason not to get the drivers ready for upstream now so
> they can funnel through netdev-2.6 into -mm with plenty of time to
> spare before the next merge window.

Agreed.  Getting something upstream is the fastest way to mature a 
driver...  It gets far less testing and review hiding out in 
netdev-2.6.git or wireless-dev.git.

If it works, is relatively clean, and doesn't corrupt data or have 
races, push it upstream :)

	Jeff

Re: Request for help...

[Axj]

Quoting Zhu Yi <yi.zhu@intel.com>:

> On Tue, 2007-07-24 at 08:02 -0700, Axj wrote:
> > so I can't compile the new version, but, even if the compilation
> is
> > not finished, when I retried to compile iwl version 0.1.2, it
> works.
> > Now for me is impossible to  understand, and I'm tring the way to
> make
> > mac802 subsys work. Can anyone help me....
> 
> iwlwifi-0.1.3 fixed this problem.
> 
> Thanks,
> -yi
> 

I tried, but peraphs I do someting wrong.... In fact without mac80211-9.0.x is impossibile to compile iwlwifi-0.1.3. But for me I'ts impossible to compile mac-802-9.0.2... give me 2 compile errors when I do "make modules", in the wmc.c. Now, if use the "make patch_kernel" of version of 9.0.2 and compile iwlwifi-0.1.3 it copilke perfect but at the moment to load the module, search a Object that doesn't exist (because if I don't compile the 9.0.2 I have to use 8.0.2). So, if I undestood good, the only way to use the driver version 0.1.x and not the version 0.0.x, is to make work the mac80211 version 9.0.2, and to resolve the compilation problem. It's no so simply like seems to be.

I  saw onother exit of thje driver, 1.0.0, but I don't trust so much (at the momente the compination of mac80211 ver 8.0.2 and iwlwifi-0.0.42 work, even if the led doesn't work ad It's impossible to set an "Ad-Hoc" connection. ) so I would like try a CVS or GIT version of the Mac80211 or newer.... I know that a lot of person think that I have to "learn to fish", but I'm a better systemist, but not a excellent programmer (expecially in kernel space). 

I would like to tel You tank you for the help.... 
I hope that one day I will give you as better answer....

----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4

Re: Request for help...

[Pavel Roskin]

On Thu, 2007-07-26 at 08:10 -0700, Axj wrote:

> I  saw onother exit of thje driver, 1.0.0, but I don't trust so much
> (at the momente the compination of mac80211 ver 8.0.2 and
> iwlwifi-0.0.42 work, even if the led doesn't work ad It's impossible
> to set an "Ad-Hoc" connection. )

Actually, it's direct continuation of the 0.0.x series.  It's
unfortunate that the complexity of the build system makes you mistrust
the recent code, although I can relate.  I hope it will be remedied
quickly.

It's possible to compile the 1.0.x driver against recent unpatched
kernels, even against the standard Fedora 7 kernel, by stripping support
for Intel's rate control algorithm:

diff --git a/origin/Makefile b/origin/Makefile
index 8c0bdc7..c5d966f 100644
--- a/origin/Makefile
+++ b/origin/Makefile
@@ -10,7 +10,7 @@
 # -jpk
 
 obj-$(CONFIG_IWL3945)	+= iwl3945.o
-iwl3945-objs		= base-3945.o iwl-3945.o iwl-3945-rs.o
+iwl3945-objs		= base-3945.o iwl-3945.o
 CFLAGS_iwl-3945.o	= -DIWL=3945
 CFLAGS_iwl-3945-rs.o	= -DIWL=3945
 CFLAGS_base-3945.o	= -DIWL=3945 -D"KBUILD_MODNAME=KBUILD_STR(iwl3945)"
@@ -19,7 +19,7 @@ $(obj)/base-3945.o: $(src)/base.c FORCE
 	$(call if_changed_rule,cc_o_c)
 
 obj-$(CONFIG_IWL4965)	+= iwl4965.o
-iwl4965-objs		= base-4965.o iwl-4965.o iwl-4965-rs.o
+iwl4965-objs		= base-4965.o iwl-4965.o
 CFLAGS_iwl-4965.o	= -DIWL=4965
 CFLAGS_iwl-4965-rs.o	= -DIWL=4965
 CFLAGS_base-4965.o	= -DIWL=4965 -D"KBUILD_MODNAME=KBUILD_STR(iwl4965)"
diff --git a/origin/base.c b/origin/base.c
index eda467e..ee6ac8f 100644
--- a/origin/base.c
+++ b/origin/base.c
@@ -6284,7 +6284,6 @@ static void iwl_alive_start(struct iwl_priv *priv)
 		/* Unlock so any user space entry points can call back into
 		 * the driver without a deadlock... */
 		mutex_unlock(&priv->mutex);
-		iwl_rate_control_register();
 		rc = ieee80211_register_hw(priv->hw);
 		priv->hw->conf.beacon_int = 100;
 		mutex_lock(&priv->mutex);
@@ -6950,7 +6949,6 @@ static void iwl_bg_post_associate(struct work_struct *data)
 				  (priv->phymode == MODE_ATHEROS_TURBO)) ?
 				 IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
 				 CMD_ASYNC);
-		iwl_rate_scale_init(priv->hw, IWL_AP_ID);
 
 		break;
 
@@ -6967,7 +6965,6 @@ static void iwl_bg_post_associate(struct work_struct *data)
 				  (priv->phymode == MODE_ATHEROS_TURBO)) ?
 				 IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
 				 CMD_ASYNC);
-		iwl_rate_scale_init(priv->hw, IWL_STA_ID);
 		iwl_send_beacon_cmd(priv);
 
 		break;
@@ -7915,8 +7912,7 @@ static ssize_t show_rs_window(struct device *d,
 			      struct device_attribute *attr,
 			      char *buf)
 {
-	struct iwl_priv *priv = d->driver_data;
-	return iwl_fill_rs_info(priv->hw, buf, IWL_AP_ID);
+	return 0;
 }
 static DEVICE_ATTR(rs_window, S_IRUGO, show_rs_window, NULL);
 
@@ -8851,7 +8847,6 @@ static void iwl_pci_remove(struct pci_dev *pdev)
 
 	if (priv->mac80211_registered) {
 		ieee80211_unregister_hw(priv->hw);
-		iwl_rate_control_unregister();
 	}
 
 	/* ieee80211_unregister_hw calls d_stop, which flushes


-- 
Regards,
Pavel Roskin

Re: Request for help...

[Axj]

I've tried the driver 0.1.4 with the new (not so new) linux kernel 2.6.22.1 (against the 2.6.21.5 installed on Slackware 12, and it work without any patch. In fact,  at the moment of compiling kernel the mac80211 subsystem is already in..... now it works (even if no led and no Ad-Hoc). I really don't try 1.0.0. I will do it. Maybe the fact of the led in only because I don't pass the right option to the modprobe (in ipw2200 was "modprobe ipw2200 led=1") but here is not. For the Ad-Hoc, i try to take a look in source, but maybe isn't present this part or I don't find. 

By the way, thank you for the advice and suggestions  


Quoting Pavel Roskin <proski@gnu.org>:

I


> On Thu, 2007-07-26 at 08:10 -0700, Axj wrote:
> 
> > I  saw onother exit of thje driver, 1.0.0, but I don't trust so
> much
> > (at the momente the compination of mac80211 ver 8.0.2 and
> > iwlwifi-0.0.42 work, even if the led doesn't work ad It's
> impossible
> > to set an "Ad-Hoc" connection. )
> 
> Actually, it's direct continuation of the 0.0.x series.  It's
> unfortunate that the complexity of the build system makes you
> mistrust
> the recent code, although I can relate.  I hope it will be
> remedied
> quickly.
> 
> It's possible to compile the 1.0.x driver against recent unpatched
> kernels, even against the standard Fedora 7 kernel, by stripping
> support
> for Intel's rate control algorithm:
> 
> diff --git a/origin/Makefile b/origin/Makefile
> index 8c0bdc7..c5d966f 100644
> --- a/origin/Makefile
> +++ b/origin/Makefile
> @@ -10,7 +10,7 @@
>  # -jpk
>  
>  obj-$(CONFIG_IWL3945)	+= iwl3945.o
> -iwl3945-objs		= base-3945.o iwl-3945.o iwl-3945-rs.o
> +iwl3945-objs		= base-3945.o iwl-3945.o
>  CFLAGS_iwl-3945.o	= -DIWL=3945
>  CFLAGS_iwl-3945-rs.o	= -DIWL=3945
>  CFLAGS_base-3945.o	= -DIWL=3945
> -D"KBUILD_MODNAME=KBUILD_STR(iwl3945)"
> @@ -19,7 +19,7 @@ $(obj)/base-3945.o: $(src)/base.c FORCE
>  	$(call if_changed_rule,cc_o_c)
>  
>  obj-$(CONFIG_IWL4965)	+= iwl4965.o
> -iwl4965-objs		= base-4965.o iwl-4965.o iwl-4965-rs.o
> +iwl4965-objs		= base-4965.o iwl-4965.o
>  CFLAGS_iwl-4965.o	= -DIWL=4965
>  CFLAGS_iwl-4965-rs.o	= -DIWL=4965
>  CFLAGS_base-4965.o	= -DIWL=4965
> -D"KBUILD_MODNAME=KBUILD_STR(iwl4965)"
> diff --git a/origin/base.c b/origin/base.c
> index eda467e..ee6ac8f 100644
> --- a/origin/base.c
> +++ b/origin/base.c
> @@ -6284,7 +6284,6 @@ static void iwl_alive_start(struct iwl_priv
> *priv)
>  		/* Unlock so any user space entry points can call back into
>  		 * the driver without a deadlock... */
>  		mutex_unlock(&priv->mutex);
> -		iwl_rate_control_register();
>  		rc = ieee80211_register_hw(priv->hw);
>  		priv->hw->conf.beacon_int = 100;
>  		mutex_lock(&priv->mutex);
> @@ -6950,7 +6949,6 @@ static void iwl_bg_post_associate(struct
> work_struct *data)
>  				  (priv->phymode == MODE_ATHEROS_TURBO)) ?
>  				 IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
>  				 CMD_ASYNC);
> -		iwl_rate_scale_init(priv->hw, IWL_AP_ID);
>  
>  		break;
>  
> @@ -6967,7 +6965,6 @@ static void iwl_bg_post_associate(struct
> work_struct *data)
>  				  (priv->phymode == MODE_ATHEROS_TURBO)) ?
>  				 IWL_RATE_6M_PLCP : IWL_RATE_1M_PLCP,
>  				 CMD_ASYNC);
> -		iwl_rate_scale_init(priv->hw, IWL_STA_ID);
>  		iwl_send_beacon_cmd(priv);
>  
>  		break;
> @@ -7915,8 +7912,7 @@ static ssize_t show_rs_window(struct device
> *d,
>  			      struct device_attribute *attr,
>  			      char *buf)
>  {
> -	struct iwl_priv *priv = d->driver_data;
> -	return iwl_fill_rs_info(priv->hw, buf, IWL_AP_ID);
> +	return 0;
>  }
>  static DEVICE_ATTR(rs_window, S_IRUGO, show_rs_window, NULL);
>  
> @@ -8851,7 +8847,6 @@ static void iwl_pci_remove(struct pci_dev
> *pdev)
>  
>  	if (priv->mac80211_registered) {
>  		ieee80211_unregister_hw(priv->hw);
> -		iwl_rate_control_unregister();
>  	}
>  
>  	/* ieee80211_unregister_hw calls d_stop, which flushes
> 
> 
> -- 
> Regards,
> Pavel Roskin
> 
>

----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4

Re: Request for help...

[Zhu Yi]

On Thu, 2007-07-26 at 23:34 -0700, Axj wrote:
> 
> I've tried the driver 0.1.4 with the new (not so new) linux kernel
> 2.6.22.1 (against the 2.6.21.5 installed on Slackware 12, and it work
> without any patch. In fact,  at the moment of compiling kernel the
> mac80211 subsystem is already in..... now it works (even if no led and
> no Ad-Hoc).

No, there is ad-hoc support in 0.1.4.

Thanks,
-yi

Re: Request for help...

[Axj]

Quoting Zhu Yi <yi.zhu@intel.com>:

> On Thu, 2007-07-26 at 23:34 -0700, Axj wrote:
> > 
> > I've tried the driver 0.1.4 with the new (not so new) linux
> kernel
> > 2.6.22.1 (against the 2.6.21.5 installed on Slackware 12, and it
> work
> > without any patch. In fact,  at the moment of compiling kernel
> the
> > mac80211 subsystem is already in..... now it works (even if no
> led and
> > no Ad-Hoc).
> 
> No, there is ad-hoc support in 0.1.4.
> 
> Thanks,
> -yi
> 


Maybe.... but don't work... from the version 0.0.36 to no tell me 

Impossible to set ...etc etc.... at the first occasion I will post up the error code that give me...

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2

Re: Request for help...

[Zhu Yi]

On Fri, 2007-07-27 at 01:48 -0700, Axj wrote:
> Maybe.... but don't work... from the version 0.0.36 to no tell me 
> 
> Impossible to set ...etc etc.... at the first occasion I will post up the error code that give me...

With mac80211 you need to change wireless mode only when the interface
is down.

$ ifconfig wlan0 down
$ iwconfig wlan0 mode ad-hoc
$ ifconfig wlan0 up

Thanks,
-yi

Re: Request for help...

[Axj]

Quoting Zhu Yi <yi.zhu@intel.com>:

> On Fri, 2007-07-27 at 01:48 -0700, Axj wrote:
> > Maybe.... but don't work... from the version 0.0.36 to no tell me
> 
> > 
> > Impossible to set ...etc etc.... at the first occasion I will
> post up the error code that give me...
> 
> With mac80211 you need to change wireless mode only when the
> interface
> is down.
> 
> $ ifconfig wlan0 down
> $ iwconfig wlan0 mode ad-hoc
> $ ifconfig wlan0 up
> 
> Thanks,
> -yi
> 
Yes I know.....

I tryed 

iwconfig wlan0 essid "lago" mode Ad-Hoc 
and then give me error....

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2

Re: [ipw3945-devel] Request for help...

[Jeff Garzik]

Whether it was in response to my ranting or not, I give credit where 
credit is due:  in the time since this thread, a lot more stuff has been 
showing up on linux-wireless.  It's great to see positive improvement 
this rapidly... thanks!

	Jeff

Re: Request for help...

[Zhu Yi]

On Fri, 2007-07-27 at 02:10 -0700, Axj wrote:
> iwconfig wlan0 essid "lago" mode Ad-Hoc 
> and then give me error.... 

What's the error?

-yi

Re: Request for help...

[Axj]

Quoting Zhu Yi <yi.zhu@intel.com>:

> On Fri, 2007-07-27 at 02:10 -0700, Axj wrote:
> > iwconfig wlan0 essid "lago" mode Ad-Hoc 
> > and then give me error.... 
> 
> What's the error?
> 
> -yi
> 

When I try the command 
 iwconfig wlan0 essid "lago" mode Ad-Hoc 

show me 

Error for wireless request Set Mode (8B06) :
    SET failed on device wlan0 ; Device or resource busy.

But if I connect with for example 

iwconfig wlan0 essid "dip-open" #my university wireless connection it works, and very well.

For this I have no explanation

----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5