headers
Bob Copeland | 1 Jun 02:32
Favicon

Re: [BUG] Crda oopses the system

On Sun, May 31, 2009 at 11:54:13PM +0300, Maxim Levitsky wrote:
> 2 - ath5k makes kernel panic, reliably after few times hostapd have
> started, I didn't yet captured the output.
> I remember to see panics with ad-hoc as well. 
> I mean blinking leds on keyboard.

This should be fixed at least with a patch I recently posted to
linux-wireless.

> 3 - couldn't transfer any frames between AP and client, only association
> works.

Yeah I still plan to fix it, just haven't found cycles for it yet.

--

-- 
Bob Copeland %% www.bobcopeland.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Zhu Yi | 1 Jun 03:29
Picon
Favicon

Re: [Announce] Intel Wireless Multicomm 3200 WiFi driver

On Sun, 2009-05-31 at 20:10 +0800, Maxim Levitsky wrote:
> This is a fullmac driver, thus if I understand correctly, it behaves
> on the outside more like an Ethernet adapter.

Depends on how you define "outside". From the user point of view: yes;
from the firmware point of view: no. Take a look at the new functions
ieee80211_data_{from|to}_8023 in cfg80211 and their usage in
iwmc3200wifi.

> This will mean that many things possible with normal softmac card
> won't be possible, like sending raw packets, etc...

See above.

> (and besides I belive that hardware is more or less the same,

The hardware is different as we mentioned it is a multicomm device.

> but more functionality is pushed down to firmware, and more firmware
> code equals to bigger probability of bugs that aren't possible to
> triage and solve easily.

That's the con. The pro is saving more host CPU power and portability.

> Does this device indicate that intel moves away from softmac devices,
> or this is a device that will mostly be used in some dedicated market
> sector (embedded devices for example)?

I think it should be capable for embedded devices as well as
desktop/laptops.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Georgy Berdyshev | 1 Jun 05:08
Picon

[GSoC 2009] Automation of testing using mac80211_hwsim and Orbit - status report 01

Automation of testing using mac80211_hwsim and Orbit

Hello Linux wireless users and kernel developers, Luis, John and Johannes,

this is the first status report of the "Automation of testing using
mac80211_hwsim and Orbit",
which is kindly sponsored by Google in the Summer of Code program and
mentored by the Linux Foundation.

http://www.linuxwireless.org/en/developers/GSoC/2009/Automation_of_testing
http://socghop.appspot.com/student_project/show/google/gsoc2009/linux_foundation/t124022664044

In the first week, I did implement a ground base for the testing
command line tool, which is written
in Python and will create statistics from the test set and later on
collect them and provide nice
statistics.

The installer, some basic commands and the parser are finished and I
did translate some of the available
tests (link from Luis) to Python. Moreover I have concentrated on
creating new tests and adding the loading
of kernel modules and setting options to the program.

By the end of the week, I did start to have some strange problems with
running hostapd (via nl80211) and using the
mac80211_hwsim kernel driver.

In case that someone did run into that problem with 2.6.30-rc5,6,7 +
latest git and latest git of hostap / wpa_supplicant,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Marcel Holtmann | 1 Jun 09:18

Re: [PATCH] rfkill: create useful userspace interface

Hi Dan,

> > > > How should userspace test CONFIG_RFKILL_INPUT to determine whether
> > > > it's safe to start the daemon?  With the old core, debian-eeepc
> > > > scripts check if the module rfkill-input exists (which should work
> > > > even if it's built in).  If it exists, the scripts don't perform any
> > > > rfkill actions.  (Yeah, according to the doc this is not allowed
> > > > because the scripts don't use "claim", but you can see how it's
> > > > useful).
> > > > 
> > > > The new rfkill-input isn't a module, so I'm not sure how your daemon
> > > > would test for it.
> > > 
> > > Maybe we should add an ioctl that disables rfkill-input if present.
> > 
> > I am against it. Can we just add a module parameter that allows us to
> > disable it. I am against cluttering a new interface with legacy stuff
> > since we are removing rfkill-input and replacing it by rfkilld anyway in
> > a near future (meaning when I am back from vacation).
> 
> Module parameter to what?  Module parameters are almost always the wrong
> thing to do.  Or, just don't built rfkill_input it into your kernel

we will make rfkill-input go away. This is just for the interim to
detect if rfkill-input is supported by the kernel or not. And it allows
to compile it into the kernel and disable it via modprobe.conf.

Regards

Marcel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Jun 09:27
Favicon

Re: [PATCH] rfkill: create useful userspace interface

On Sun, 2009-05-31 at 21:03 +0200, Marcel Holtmann wrote:

> > Maybe we should add an ioctl that disables rfkill-input if present.
> 
> I am against it. Can we just add a module parameter that allows us to
> disable it. I am against cluttering a new interface with legacy stuff
> since we are removing rfkill-input and replacing it by rfkilld anyway in
> a near future (meaning when I am back from vacation).

Right. But you'll get a bunch of people get it mixed up. I think I would
prefer adding the ioctl, but having it only when rfkill-input is
compiled in, so userspace would always just get -ENOSYS if there's no
rfkill-input present, which means the "cluttering" of the interface
occurs only for as long as we have rfkill-input and at some point you
would just remove that one line of code from rfkilld.

johannes
Permalink | Reply | 2 comments |
headers
Kalle Valo | 1 Jun 09:29
Picon
Picon
Favicon

Re: commit #1868cf308a3b3a336fcfe52c5aea4ac12d5e42ac breaks wireless on my system

Maxim Levitsky <maximlevitsky@...> writes:

> It appears that I don't receive half of mails of linux-wireless
> nether they are in spam folder.
>
> I am subscribed to linux-wireless@...>
>
> For example I see no trace of new intel fullmac driver.
>
> Is gmail that bad?

I'm using gmail (iki.fi just forwards everything to gmail) and FWIW I
haven't noticed any problems with linux-wireless.

--

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Jun 09:33
Favicon

Re: [PATCH] rfkill: create useful userspace interface

On Sun, 2009-05-31 at 21:01 +0200, Marcel Holtmann wrote:

> > You have a point there, but I'm not sure it even cares? When restarted
> > it will probably want to impose its current policy anyway? It would be
> > easy to add that we send the global default value for newly added ones
> > too but I'm not sure it's necessary -- Marcel?
> 
> we can be smart and send an additional CHANGE_ALL when opening the
> control device if it is set. We can also just send these anyway. Doesn't
> really matter? Does it?

Well, I don't think we want/need this.

See, Henrique says that the use case is Thinkpads which store the
previous state in the BIOS. But that matters to you only if you use a
mixture of operation systems, which we don't have to support.

On the other hand, people on machines that don't store the rfkill state
in the BIOS might care about having their machine boot up with the same
rfkill state(s) as they shut down with, so the sane thing to do would be
to have rfkilld store the state persistently, and then recover it at
boot. At which point the BIOS state becomes irrelevant and a detail we
actually end up not even _wanting_ to support because it means we need
to be aware of machine differences in userspace.

johannes
Permalink | Reply | 72 comments |
headers
Alan Jenkins | 1 Jun 09:40
Picon
Favicon

Re: [PATCH] rfkill: create useful userspace interface

Johannes Berg wrote:
> On Sun, 2009-05-31 at 21:03 +0200, Marcel Holtmann wrote:
>
>   
>>> Maybe we should add an ioctl that disables rfkill-input if present.
>>>       
>> I am against it. Can we just add a module parameter that allows us to
>> disable it. I am against cluttering a new interface with legacy stuff
>> since we are removing rfkill-input and replacing it by rfkilld anyway in
>> a near future (meaning when I am back from vacation).
>>     
>
> Right. But you'll get a bunch of people get it mixed up. I think I would
> prefer adding the ioctl, but having it only when rfkill-input is
> compiled in, so userspace would always just get -ENOSYS if there's no
> rfkill-input present, which means the "cluttering" of the interface
> occurs only for as long as we have rfkill-input and at some point you
> would just remove that one line of code from rfkilld.
>
> johannes
>   

Yeah, that's much better.  If you had a module parameter then you would 
have to keep it around, even after the removal of the kernel 
rfkill-input.  Otherwise people have to change modprobe.conf _again_ 
when they upgrade the kernel, because rfkill-as-module will refuse to load.

Thanks
Alan
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Jenkins | 1 Jun 10:17
Picon
Favicon

Re: [PATCH] rfkill: create useful userspace interface

Johannes Berg wrote:
> On Sun, 2009-05-31 at 21:01 +0200, Marcel Holtmann wrote:
>
>   
>>> You have a point there, but I'm not sure it even cares? When restarted
>>> it will probably want to impose its current policy anyway? It would be
>>> easy to add that we send the global default value for newly added ones
>>> too but I'm not sure it's necessary -- Marcel?
>>>       
>> we can be smart and send an additional CHANGE_ALL when opening the
>> control device if it is set. We can also just send these anyway. Doesn't
>> really matter? Does it?
>>     
>
> Well, I don't think we want/need this.
>
> See, Henrique says that the use case is Thinkpads which store the
> previous state in the BIOS. But that matters to you only if you use a
> mixture of operation systems, which we don't have to support.
>   

"Other OS's" also includes the BIOS.  My BIOS setup screen has an option 
to toggle the wireless state.  It's great to have this just work, and 
annoying to have regressions.

And it's not a "mixture" of operating systems if you dual-boot linux, 
but that will have the same problem.  We'll get rather weird behaviour 
if you dual boot A and B, where linux version A restores state to a 
file, and linux version B uses the hardware persistent state.
(Continue reading)

Permalink | Reply | 71 comments |
headers
Luis Galdos | 1 Jun 11:32
Favicon

Re: [LIBERTAS-SDIO] Support for single transfer blocks?

Pierre Ossman wrote:
>>> On Mon, 11 May 2009 16:41:51 +0200 Luis Galdos <luis.galdos@...> wrote:
>>>> * The transfer of Ethernet-frames works only if the "complete" frame is smaller than the 
>>>> block size of the SDIO-host. By larger packages, the SD8686 doesn't generate the expected 
>>>> IRQ (cause it expected a multiple transfer) and the driver detects a timeout.
>>>>
> 
> Unfortunately, the libertas chip cannot support your host as it
> requires everything to be done in a single transaction. So I'm afraid
> you'll have to look at another host controller or another wifi chip.
Thanks a lot for this info, this confirms my expectation. And sorry for the delayed 
feedback (I was on vacations).

> Rgds
Regards,

--

-- 
Luis Galdos
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane