* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Gregory Haskins @ 2009-08-06 16:55 UTC (permalink / raw)
To: Arnd Bergmann, Avi Kivity
Cc: alacrityvm-devel, Michael S. Tsirkin, kvm, linux-kernel, netdev
In-Reply-To: <4A7AFBE3.5080200@redhat.com>
>>> On 8/6/2009 at 11:50 AM, in message <4A7AFBE3.5080200@redhat.com>, Avi Kivity
<avi@redhat.com> wrote:
> On 08/06/2009 06:40 PM, Arnd Bergmann wrote:
>> 3. The ioq method seems to be the real core of your work that makes
>> venet perform better than virtio-net with its virtqueues. I don't see
>> any reason to doubt that your claim is correct. My conclusion from
>> this would be to add support for ioq to virtio devices, alongside
>> virtqueues, but to leave out the extra bus_type and probing method.
>>
>
> The current conjecture is that ioq outperforms virtio because the host
> side of ioq is implemented in the host kernel, while the host side of
> virtio is implemented in userspace. AFAIK, no one pointed out
> differences in the protocol which explain the differences in performance.
There *are* protocol difference that matter, though I think they are slowly being addressed.
For an example: Earlier versions of virtio-pci had a single interrupt for all ring events, and you had to do an extra MMIO cycle to learn the proper context. That will hurt...a _lot_ especially for latency. I think recent versions of KVM switched to MSI-X per queue which fixed this particular ugly.
However, generally I think Avi is right. The main reason why it outperforms virtio-pci by such a large margin has more to do with all the various inefficiencies in the backend (such as requiring multiple hops U->K, K->U per packet), coarse locking, lack of parallel processing, etc. I went through and streamlined all the bottlenecks (such as putting the code in the kernel, reducing locking/context switches, etc).
I have every reason to believe that someone will skills/time equal to myself could develop a virtio-based backend that does not use vbus and achieve similar numbers. However, as stated in my last reply, I am interested in this backend supporting more than KVM, and I designed vbus to fill that role. Therefore, it does not interest me to endeavor such an effort if it doesn't involve a backend that is independent of KVM.
Based on this, I will continue my efforts surrounding to use of vbus including its use to accelerate KVM for AlacrityVM. If I can find a way to do this in such a way that KVM upstream finds acceptable, I would be very happy and will work towards whatever that compromise might be. OTOH, if the KVM community is set against the concept of a generalized/shared backend, and thus wants to use some other approach that does not involve vbus, that is fine too. Choice is one of the great assets of open source, eh? :)
Kind Regards,
-Greg
^ permalink raw reply
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Arnd Bergmann @ 2009-08-06 17:03 UTC (permalink / raw)
To: Gregory Haskins; +Cc: alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4A7AC5BC0200005A00051C2A@sinclair.provo.novell.com>
On Thursday 06 August 2009, you wrote:
> >>> On 8/6/2009 at 10:42 AM, in message <200908061642.40614.arnd@arndb.de>, Arnd
> Bergmann <arnd@arndb.de> wrote:
> > On Monday 03 August 2009, Gregory Haskins wrote:
> >> This patch adds a pci-based driver to interface between the a host VBUS
> >> and the guest's vbus-proxy bus model.
> >>
> >> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
> >
> > This seems to be duplicating parts of virtio-pci that could be kept
> > common by extending the virtio code. Layering on top of virtio
> > would also make it possible to use the same features you add
> > on top of other transports (e.g. the s390 virtio code) without
> > adding yet another backend for each of them.
>
> This doesn't make sense to me, but I suspect we are both looking at what this
> code does differently. I am under the impression that you may believe that
> there is one of these objects per vbus device. Note that this is just a bridge
> to vbus, so there is only one of these per system with potentially many vbus
> devices behind it.
Right, this did not become clear from the posting. For virtio, we discussed
a model like this in the beginning and then rejected it in favour of a
"one PCI device per virtio device" model, which I now think is a better
approach than your pci-to-vbus bridge.
> In essence, this driver's job is to populate the "vbus-proxy" LDM bus with
> objects that it finds across the PCI-OTHER bridge. This would actually sit
> below the virtio components in the stack, so it doesnt make sense (to me) to
> turn around and build this on top of virtio. But perhaps I am missing
> something you are seeing.
>
> Can you elaborate?
Your PCI device does not serve any real purpose as far as I can tell, you
could just as well have a root device as a parent for all the vbus devices
if you do your device probing like this.
However, assuming that you do the IMHO right thing to do probing like
virtio with a PCI device for each slave, the code will be almost the same
as virtio-pci and the two can be the same.
> > This seems to add an artificial abstraction that does not make sense
> > if you stick to the PCI abstraction.
>
> I think there may be confusion about what is going on here. The "device-open"
> pertains to a vbus device *beyond* the bridge, not the PCI device (the bridge)
> itself. Nor is the vbus device a PCI device.
>
> Whats happening here is somewhat analogous to a PCI config-cycle. Its
> a way to open a channel to a device beyond the bridge in _response_ to
> a probe.
>
> We have a way to enumerate devices present beyond the bridge (this yields
> a "device-id") but in order to actually talk to the device, you must first
> call DEVOPEN(id). When a device-id is enumerated, it generates a probe()
> event on vbus-proxy. The responding driver in question would then turn
> around and issue the handle = dev->open(VERSION) to see if it is compatible
> with the device, and to establish a context for further communication.
>
> The reason why DEVOPEN returns a unique handle is to help ensure that the
> driver has established proper context before allowing other calls.
So assuming this kind of bus is the right idea (which I think it's not),
why can't the host assume they are open to start with and you go and
enumerate the devices on the bridge, creating a vbus_device for each
one as you go. Then you just need to match the vbus drivers with the
devices by some string or vendor/device ID tuple.
> >
> > This could be implemented by virtio devices as well, right?
>
> The big difference with dev->shm() is that it is not bound to
> a particular ABI within the shared-memory (as opposed to
> virtio, which assumes a virtio ABI). This just creates a
> n empty shared-memory region (with a bidirectional signaling
> path) which you can overlay a variety of structures (virtio
> included). You can of course also use non-ring based
> structures, such as, say, an array of idempotent state.
>
> The point is that, once this is done, you have a shared-memory
> region and a way (via the shm-signal) to bidirectionally signal
> changes to that memory region. You can then build bigger
> things with it, like virtqueues.
Let me try to rephrase my point: I believe you can implement
the shm/ioq data transport on top of the virtio bus level, by
adding shm and signal functions to struct virtio_config_ops
alongside find_vqs() so that a virtio_device can have either
any combination of virtqueues, shm and ioq.
> > static int
> > vbus_pci_device_call(struct vbus_device_proxy *vdev, u32 func, void *data,
> > size_t len, int flags)
> > {
> > struct vbus_pci_device *dev = to_dev(vdev);
> > struct vbus_pci_hypercall params = {
> > .vector = func,
> > .len = len,
> > .datap = __pa(data),
> > };
> > spin_lock_irqsave(&dev.lock, flags);
> > memcpy_toio(&dev.regs->hypercall.data, ¶ms, sizeof(params));
> > ret = ioread32(&dev.regs->hypercall.result);
> > spin_unlock_irqrestore(&dev.lock, flags);
> >
> > return ret;
> > }
> >
> > This gets rid of your 'handle' and the unwinding through an extra pointer
> > indirection. You just need to make sure that the device specific call
> > numbers
> > don't conflict with any global ones.
>
> Ah, now I see the confusion...
>
> DEVCALL is sending a synchronous call to a specific device beyond the bridge. The MMIO going on here against dev.regs->hypercall.data is sending a synchronous call to the bridge itself. They are distinctly different ;)
well, my point earlier was that they probably should not be different ;-)
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3] documentation: fix wrt. headers rename
From: David Miller @ 2009-08-06 17:34 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <20090806092617.GA9209@doriath.ww600.siemens.net>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu, 6 Aug 2009 13:26:17 +0400
> BTW: how should I differentiate my poll requests for net-next-2.6 and
> for net-2.6 ?
Like the rest of the world by indicating the target tree in your
subject lines. As long as it's in those initial [] brackets,
the automated GIT tools strip it all out when applying patches.
Don't you see other patch posters putting things like "[NEXT ...]" and
"[net-2.6 ...]" and "[net-next-2.6 ...]" in their subjects?
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: David Miller @ 2009-08-06 17:40 UTC (permalink / raw)
To: joamaki; +Cc: netdev
In-Reply-To: <ce10d01f0908052332o1db16460k58ed47849670c6de@mail.gmail.com>
From: Jussi Maki <joamaki@gmail.com>
Date: Thu, 6 Aug 2009 09:32:37 +0300
> Should I pursue with fixing the inlining issue in my patch or would
> you have any suggestions how I could
> fix this by perhaps modifying __xfrm4_daddr_saddr_hash?
Do some different mixing in __xfrm4_daddr_saddr_hash(), it's still
going to be cheaper than jhash.
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: David Miller @ 2009-08-06 17:40 UTC (permalink / raw)
To: jmaki; +Cc: joamaki, netdev
In-Reply-To: <alpine.DEB.1.10.0908061147060.3426@sisapiiri.net.net>
From: Jussi Maki <jmaki@sisapiiri.net.net>
Date: Thu, 6 Aug 2009 11:58:55 +0300 (EEST)
> Did some testing and one possible fix to this problem
> would be to change the xor to addition. Would this be OK?
Yes.
Please make a formal submission.
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Paul Moore @ 2009-08-06 18:09 UTC (permalink / raw)
To: David Miller; +Cc: Eric W. Biederman, Herbert Xu, netdev
In-Reply-To: <m1zladhtoh.fsf@fess.ebiederm.org>
On Thursday 06 August 2009 11:02:22 am Eric W. Biederman wrote:
> Herbert Xu <herbert@gondor.apana.org.au> writes:
> > On Thu, Aug 06, 2009 at 07:27:13AM -0700, Eric W. Biederman wrote:
> >> Summarizing:
> >>
> >> tun = __tun_get(tfile);
> >> if (!tun) { // No tun we are not attached.
> >> < -------------------- race opportunity
> >> rtnl_lock();
> >> tun_set_iff();
> >> rtnl_unlock();
> >> }
> >> ...
> >>
> >> We don't test if we are attached under the rtnl
> >> until we get to tun_attach();
> >>
> >> So two threads can both do:
> >>
> >> tun = __tun_get(tfile);
> >> if (!tun) {
> >> rtnl_lock();
> >> tun_set_iff();
> >> dev = __dev_get_by_name(net, "not_an_interface_name");
> >> if (!dev) {
> >> dev = alloc_netdev(....);
> >> ...;
> >> register_netdev(dev);
> >> ...;
> >> err = tun_attach(..);
> >> }
> >>
> >>
> >> Only one thread is in tun_set_iff() at a time, but the other thread
> >> could have attached the file to a device before the one in tun_attach().
> >
> > Right, I see what you mean. However I don't think this is possible
> > because the ioctl runs under the big kernel lock.
>
> Why not? We can sleep on that code path.
> Although now that you mention it we should use unlocked_ioctl unless
> we actually need the BKL.
Dave, if you haven't already, it is probably a good idea to just forget about
this patch. Prior to this discussion I suspected that the TUN driver could
use a closer look, after reading the comments from Eric and Herbert there
isn't much suspicion left. I'll put this on my rainy day todo list to try and
tackle but I won't be upset if somebody beats me to it.
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Paul Moore @ 2009-08-06 18:20 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, David Miller, Herbert Xu
In-Reply-To: <m1ws5hua4h.fsf@fess.ebiederm.org>
On Wednesday 05 August 2009 07:14:06 pm Eric W. Biederman wrote:
> Paul Moore <paul.moore@hp.com> writes:
> > On Wednesday 05 August 2009 01:32:49 am Eric W. Biederman wrote:
> >> Paul Moore <paul.moore@hp.com> writes:
> >> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >> > index 4a0db7a..b6d06fd 100644
> >> > --- a/drivers/net/tun.c
> >> > +++ b/drivers/net/tun.c
> >> > @@ -976,10 +973,11 @@ static int tun_set_iff(struct net *net, struct
> >> > file *file, struct ifreq *ifr) tun->flags = flags;
> >> > tun->txflt.count = 0;
> >> >
> >> > - err = -ENOMEM;
> >> > sk = sk_alloc(net, AF_UNSPEC, GFP_KERNEL, &tun_proto);
> >> > - if (!sk)
> >> > + if (!sk) {
> >> > + err = -ENOMEM;
> >> > goto err_free_dev;
> >> > + }
> >>
> >> Trivially correct but I would argue uglier.
> >
> > My reasoning behind the change was that code related to the error
> > handling should be moved outside the common path as much as possible
> > similar to what we do now with the gotos.
>
> I don't understand. Generating less readable and less efficient code is
> preferable?
While we can probably debate the "readability" of code all day long and get no
where (anyone care to argue about the color of the bikeshed?) the concept of
code efficiency should be a bit easier to quantify. I'll admit that I'm far
from a performance expert but here is my reasoning ...
The code currently looks something like this:
err = -ENOMEM;
buf = alloc(...);
if (!buf)
goto label;
This means that in the common case where 'alloc()' completes without error we
are doing an extra, unnecessary assignment where we set the value in 'err'.
Now, if we change this slightly to match what I proposed in the patch:
buf = alloc(...);
if (!buf) {
err = -ENOMEM;
goto label;
}
We eliminate that extra assignment in the case where 'alloc()' completes
without error, which should result in more efficient code (less instructions
in the common case). Am I wrong? If that is the case I would appreciate an
explanation ...
--
paul moore
linux @ hp
^ permalink raw reply
* WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Fabio Comolli @ 2009-08-06 18:30 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev; +Cc: Rafael J. Wysocki
Just got this after a resume from suspend-to-ram. Wifi needed to be
disabled and reenabled (with hardware Fn+F2 key - this is an eeePC900)
to function again.
[ 919.858759] ------------[ cut here ]------------
[ 919.858787] WARNING: at net/mac80211/mlme.c:2292
ieee80211_sta_work+0x97/0xd2d [mac80211]()
[ 919.858791] Hardware name: 900
[ 919.858793] Modules linked in: uvcvideo videodev v4l1_compat arc4
ecb ath5k mac80211 ath cfg80211
[ 919.860022] Pid: 793, comm: phy0 Tainted: G M 2.6.31-rc5 #11
[ 919.860025] Call Trace:
[ 919.860035] [<c10209cf>] warn_slowpath_common+0x65/0x7c
[ 919.860058] [<f83d621e>] ? ieee80211_sta_work+0x97/0xd2d [mac80211]
[ 919.860064] [<c10209f3>] warn_slowpath_null+0xd/0x10
[ 919.860086] [<f83d621e>] ieee80211_sta_work+0x97/0xd2d [mac80211]
[ 919.860092] [<c101bb2b>] ? __wake_up+0x2f/0x56
[ 919.860097] [<c101bb39>] ? __wake_up+0x3d/0x56
[ 919.860103] [<c102eb04>] ? insert_work+0x96/0x9f
[ 919.860108] [<c102ed63>] ? __queue_work+0x32/0x49
[ 919.860113] [<c102eda1>] ? queue_work_on+0x27/0x2f
[ 919.860119] [<c102f52f>] ? queue_work+0x2d/0x45
[ 919.860140] [<f83d3324>] ?
ieee80211_ibss_notify_scan_completed+0x63/0x68 [mac80211]
[ 919.860162] [<f83d1059>] ? ieee80211_scan_completed+0x320/0x328 [mac80211]
[ 919.860184] [<f83d1160>] ? ieee80211_scan_work+0xb5/0x171 [mac80211]
[ 919.860190] [<c102f075>] worker_thread+0x15d/0x204
[ 919.860211] [<f83d6187>] ? ieee80211_sta_work+0x0/0xd2d [mac80211]
[ 919.860218] [<c1032217>] ? autoremove_wake_function+0x0/0x2f
[ 919.860223] [<c102ef18>] ? worker_thread+0x0/0x204
[ 919.860229] [<c1031fab>] kthread+0x63/0x68
[ 919.860234] [<c1031f48>] ? kthread+0x0/0x68
[ 919.860240] [<c1002f93>] kernel_thread_helper+0x7/0x10
[ 919.860244] ---[ end trace 7a3a8d08c5a7bedf ]---
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: John W. Linville @ 2009-08-06 18:32 UTC (permalink / raw)
To: Fabio Comolli
Cc: Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA,
Rafael J. Wysocki, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b637ec0b0908061130w399eb1c6oc3a31640a76398c5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
What driver are you using?
On Thu, Aug 06, 2009 at 08:30:23PM +0200, Fabio Comolli wrote:
> Just got this after a resume from suspend-to-ram. Wifi needed to be
> disabled and reenabled (with hardware Fn+F2 key - this is an eeePC900)
> to function again.
>
>
> [ 919.858759] ------------[ cut here ]------------
> [ 919.858787] WARNING: at net/mac80211/mlme.c:2292
> ieee80211_sta_work+0x97/0xd2d [mac80211]()
> [ 919.858791] Hardware name: 900
> [ 919.858793] Modules linked in: uvcvideo videodev v4l1_compat arc4
> ecb ath5k mac80211 ath cfg80211
> [ 919.860022] Pid: 793, comm: phy0 Tainted: G M 2.6.31-rc5 #11
> [ 919.860025] Call Trace:
> [ 919.860035] [<c10209cf>] warn_slowpath_common+0x65/0x7c
> [ 919.860058] [<f83d621e>] ? ieee80211_sta_work+0x97/0xd2d [mac80211]
> [ 919.860064] [<c10209f3>] warn_slowpath_null+0xd/0x10
> [ 919.860086] [<f83d621e>] ieee80211_sta_work+0x97/0xd2d [mac80211]
> [ 919.860092] [<c101bb2b>] ? __wake_up+0x2f/0x56
> [ 919.860097] [<c101bb39>] ? __wake_up+0x3d/0x56
> [ 919.860103] [<c102eb04>] ? insert_work+0x96/0x9f
> [ 919.860108] [<c102ed63>] ? __queue_work+0x32/0x49
> [ 919.860113] [<c102eda1>] ? queue_work_on+0x27/0x2f
> [ 919.860119] [<c102f52f>] ? queue_work+0x2d/0x45
> [ 919.860140] [<f83d3324>] ?
> ieee80211_ibss_notify_scan_completed+0x63/0x68 [mac80211]
> [ 919.860162] [<f83d1059>] ? ieee80211_scan_completed+0x320/0x328 [mac80211]
> [ 919.860184] [<f83d1160>] ? ieee80211_scan_work+0xb5/0x171 [mac80211]
> [ 919.860190] [<c102f075>] worker_thread+0x15d/0x204
> [ 919.860211] [<f83d6187>] ? ieee80211_sta_work+0x0/0xd2d [mac80211]
> [ 919.860218] [<c1032217>] ? autoremove_wake_function+0x0/0x2f
> [ 919.860223] [<c102ef18>] ? worker_thread+0x0/0x204
> [ 919.860229] [<c1031fab>] kthread+0x63/0x68
> [ 919.860234] [<c1031f48>] ? kthread+0x0/0x68
> [ 919.860240] [<c1002f93>] kernel_thread_helper+0x7/0x10
> [ 919.860244] ---[ end trace 7a3a8d08c5a7bedf ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
From: Serge E. Hallyn @ 2009-08-06 18:38 UTC (permalink / raw)
To: Paul Moore; +Cc: eparis, netdev, linux-security-module, selinux
In-Reply-To: <200908061225.47404.paul.moore@hp.com>
Quoting Paul Moore (paul.moore@hp.com):
> On Thursday 06 August 2009 11:52:58 am Serge E. Hallyn wrote:
> > Quoting Paul Moore (paul.moore@hp.com):
> > > BTW, the main reason for posting the patches in such an early state was
> > > to solicit feedback on the location and types of hooks added; I've read
> > > lots of good feedback but nothing regarding the fundamental aspects of
> > > the hooks ... any comments before I push out v2?
> >
> > Oh now that you mention it, yes - I think the security_tun_dev_attach()
> > should be called again separately after the post_create() hook.
>
> Why? Granted the TUN driver calls tun_attach() in both cases but that doesn't
> necessarily mean the operation from a security point of view is the same.
> Using the SELinux hooks as an example, attaching to an existing TUN device is
> currently treated as a relabel operation; the calling task relabels the
> persistent TUN device to match its own label so that traffic sent over the TUN
> device is labeled using the newly attached calling task's label. Creating a
> new TUN device is like creating any other object (yes, there are exceptions to
> this but I'm speaking generally here), it inherits the label of the task which
> creates it, performing access control for a relabel operation here just
> doesn't make sense.
>
> Or are you expecting some other form of access control for the attach hook
> which would change this argument?
You're right, since there is no way to create without attaching that doesn't
make sense, regardless of the LSM or policy :) Nm.
> > As for more general comments on whether or which tuntap-specific hooks
> > need to exist, two things. First, if you have specific requirements
> > in mind please do share those, otherwise I'm working based on what I
> > see in Documentation/networking/tuntap.txt and drivers/net/tun.c.
>
> Not that haven't already been mentioned. If something doesn't make sense, let
> me know.
>
> > Second, based on my understanding i think the hooks you have make sense,
> > but is there any way to relabel a tun socket? Since they are always labeled
> > with current_sid(), that seems restrictive...
>
> Not at present, the TUN driver only supports changing the user/group IDs. I
> am debating adding support to change/view the label of the device/socket
> (TUN{SET,GET}SECCTX perhaps?) but that can happen later and is in no way
> prevented by these patches. My thinking is that these patches are a
> requirement for us to apply the existing LSM network access controls to
> traffic originating from the TUN driver; depending on how use cases evolve
> with the TUN driver we may want to add additional functionality but this
> should serve as a good base.
>
> > I see that you don't want to use sockcreate_sid, but (to use a made-up
> > example not reflecting reality) a kvm_setup_t task couldn't create a tun
> > sock for a kvm_run_t task to use, right?
>
> Well, the only time this will really be an issue is when you have one task
> create a new, persistent TUN device and a second task that attaches to the
> existing TUN device and uses it to send traffic. Sticking with your example,
> if the first task is labeled kvm_setup_t and the second task is labeled
> kvm_run_t then the policy would look something like this:
>
> # allow kvm_setup_t to create a new TUN device
> allow kvm_setup_t self:tun_socket { create };
>
> # allow kvm_run_t to use TUN devices created by kvm_setup_t
> allow kvm_run_t kvm_setup_t:tun_socket { relabelfrom };
> allow kvm_run_t self:tun_socket { relabelto };
>
> The policy above has the nice effect of only allowing kvm_run_t to attach to
> existing TUN devices created by kvm_setup_t; it can not create a new TUN
> device or use persistent TUN devices created by other domains. This should
> also help explain why I think calling the attach() hook after the
> post_create() hook makes little sense given the access controls currently
> proposed.
And really allowing flexibility in the default label can always be done
without affecting the tun code so never mind.
So I think your hooks make sense as is, given the TUN usage model described
in the docs.
thanks,
-serge
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: David Miller @ 2009-08-06 18:41 UTC (permalink / raw)
To: paul.moore; +Cc: ebiederm, herbert, netdev
In-Reply-To: <200908061409.19924.paul.moore@hp.com>
From: Paul Moore <paul.moore@hp.com>
Date: Thu, 6 Aug 2009 14:09:19 -0400
> Dave, if you haven't already, it is probably a good idea to just
> forget about this patch.
ok.
^ permalink raw reply
* pull request: wireless-next-2.6 2009-08-06
From: John W. Linville @ 2009-08-06 19:02 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is another big round of updates intended for 2.6.32...mostly the usual
suspects, although it looks like Luis has been exceptionally busy with
both ath9k and regulatory enforcement bits. Jussi has a number of
rndis_wlan changes, and of course Johannes has a number of patches as
well.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit e4c4e448cf557921ffbbbd6d6ddac81fdceacb4f:
Eric Dumazet (1):
neigh: Convert garbage collection from softirq to workqueue
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Andrey Yurovsky (1):
libertas: check valid bits in SPI bus mode reg
Bob Copeland (3):
mac80211: disable beacons before removing the associated interface
ath5k: update PCU opmode whenever a new interface is added
ath5k: fix CAB queue operation
Daniel C Halperin (1):
iwlwifi: clear iwl_cmd_meta structure before use
Gábor Stefanik (1):
b43: implement baseband init for LP-PHY <= rev1
Holger Schurig (1):
orinoco: enable cfg80211 "set_channel" operation
Igor Perminov (1):
mac80211: FIF_PSPOLL filter flag
Ivo van Doorn (1):
rt2x00: Fix build error when crypto support is disabled
Jay Sternberg (1):
iwlwifi: remove duplicated version info from sysfs
Johannes Berg (8):
mac80211: disable software retry for now
cfg80211: keep track of current_bss for userspace SME
mac80211: fix sparse warnings/errors
iwlwifi: don't export symbols not needed in other modules
cfg80211: fix NETDEV_UNREGISTER notifier
mac80211: fix powersave
cfg80211: lower dynamic PS timeout to 100ms
cfg80211: clear SSID on disconnect/no connection
Julia Lawall (1):
drivers/net/wireless: Use DIV_ROUND_CLOSEST
Jussi Kivilinna (10):
usbnet: allow "minidriver" to prevent urb unlinking on usbnet_stop
rndis_wlan: stop workers on rndis_wlan_stop() and restore on rndis_wlan_reset()
rndis_wlan: clear cfg80211 scan on rndis_wlan_stop()
rndis_wlan: reset device and restore multicast list on rndis_wlan_reset()
rndis_wlan: set current packet filter to zero on stop
rndis_wlan: add rndis_set/query_oid debugging
rndis_host: allow rndis_wlan to see all indications
rndis_wlan: handle 802.11 indications from device
rndis_wlan: add missing padding to struct rndis_80211_remove_key
rndis_wlan: rework key handling
Larry Finger (2):
b43: Work around mac80211 race condition
b43legacy: Work around mac80211 race condition
Luis R. Rodriguez (51):
ath9k: re-order cancelling of work on mac80211 workqueue
ath9k: move cancel_delayed_work_sync() out of ath_deinit_leds()
ath9k: move workqueue cancels to stop callback
ar76c50x-usb: cancel promisc work during mac80211 stop
at76c50x-usb: cancel scan work at stop callback
ar9170: remove unneeded flush_workqueue()
wext: remove extra return on wireless_nlevent_init()
ath: depend on cfg80211
ath: simplify kconfig dependency and add documentation
ath: use menuconfig to put ath stuff in its own page
ath5k: remove EXPERIMENTAL marker
wireless: use menuconfig for WLAN_PRE80211 and WLAN_80211
rt2x00: move experimental on kconfig only to rt2800usb
ar9170: remove EXPERIMENTAL marker
at76c50x-usb: remove unneeded flush_workqueue() at usb disconnect
mac80211: redefine usage of the mac80211 workqueue
cfg80211: use goto out on country IE reg hint failure
cfg80211: do not iterate over rdev list on country IE hint
cfg80211: decouple regulatory variables from cfg80211_mutex
cfg80211: enable country IE support to all cfg80211 drivers
iwlwifi: remove usage of orig_flags
ath9k: remove usage of AR_SREV_*() wrapper to detect supported hw
ath9k: use a switch for revising supported hw mac revisions
ath9k: propagate hw initialization errors
ath9k: move memory allocation of ath_hw to ath_init()
ath9k: move devid cache setting to ath_init()
ath9k: move cache setting of softc ah prior to attach
ath9k: call hw initializer directly
ath9k: pass only one argument to hw attach
ath9k: move hw macrevision checker to helper
ath9k: rename ath9k_hw_newstate() to ath9k_hw_init_defaults()
ath9k: rename ath9k_hw_set_defaults() to ath9k_hw_init_config()
ath9k: remove debug message for no memoery on ath_init()
ath9k: break up hw initialization into a few more helpers
ath9k: describe hw initialization better
ath9k: distinguish between device initialization and ath_softc init
ath9k: remove !NULL check before kfree()
ath9k: use helper macro to kfree and nullify on ath9k_hw_rfdetach()
ath9k: rename ath9k_hw_rfdetach() to ath9k_hw_rf_free()
ath9k: rename ath9k_hw_ani_detach() to ath9k_hw_ani_disable()
ath9k: set ah to null after freeing
ath9k: set sc->sc_ah to NULL after freeing it
ath9k: call ath9k_hw_detach() once upon hw init failure
ath9k: remove dangling error check on keycache reset on hw init
ath9k: remove spurious check for channel on keycache reset
ath9k: Remove _t postfix for ar9287_eeprom structure
ath9k: add ar9271 revision and subrevision ID helpers
ath9k: add initvals and registry definitions for AR9271
ath9k: add initial hardware support for ar9271
ath9k: cancel xmit poll work at stop() callback
ath9k: fix compile warning on ath9k_hw_AR9287_check_eeprom()
Maithili Hinge (1):
libertas: Fix WEP association failure with open source wpa_supplicant 0.5.10
Maxim Levitsky (2):
mac80211: Retry probe request few times
mac80211: Increase timeouts for station polling
Michael Buesch (1):
b43: Fix unaligned 32bit SHM-shared access
Pavel Roskin (2):
rt61pci: fix module reloading
rt2x00: cancel all work on disconnect
Tomas Winkler (1):
rfkill: add the GPS radio type
Vasanthakumar Thiagarajan (3):
ath9k: Update rate control for 11NA HT40 mode
ath9k: Maintain monotonicity of PER while going across different phy
ath9k: Remove unused ath9k_hw_intrget()
Wey-Yi Guy (2):
iwlwifi: Distinguish power amplifier for 6000 series
iwlwifi: remove deprecated 6000 series adapters
Zhu Yi (3):
iwmc3200wifi: fix set_wpa_version and set_auth_type order
iwmc3200wifi: set WEP key static flag correctly
iwmc3200wifi: avoid setting default key for 802.1X and RSNA
gregor kowski (1):
b43: remove wrong probe_resp_plcp write
drivers/net/usb/rndis_host.c | 48 ++-
drivers/net/usb/usbnet.c | 32 +-
drivers/net/wireless/Kconfig | 4 +-
drivers/net/wireless/at76c50x-usb.c | 18 +-
drivers/net/wireless/ath/Kconfig | 21 +-
drivers/net/wireless/ath/ar9170/Kconfig | 4 +-
drivers/net/wireless/ath/ar9170/led.c | 11 +-
drivers/net/wireless/ath/ar9170/main.c | 29 +-
drivers/net/wireless/ath/ath5k/Kconfig | 3 +-
drivers/net/wireless/ath/ath5k/base.c | 8 +-
drivers/net/wireless/ath/ath9k/Kconfig | 1 -
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/ani.h | 4 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/calib.c | 106 ++++-
drivers/net/wireless/ath/ath9k/eeprom.c | 175 +++++--
drivers/net/wireless/ath/ath9k/eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/hw.c | 368 +++++++++------
drivers/net/wireless/ath/ath9k/hw.h | 11 +-
drivers/net/wireless/ath/ath9k/initvals.h | 666 ++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/main.c | 89 +++--
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
drivers/net/wireless/ath/ath9k/phy.c | 53 +--
drivers/net/wireless/ath/ath9k/phy.h | 3 +
drivers/net/wireless/ath/ath9k/rc.c | 7 +-
drivers/net/wireless/ath/ath9k/reg.h | 37 ++
drivers/net/wireless/ath/ath9k/virtual.c | 17 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/net/wireless/b43/b43.h | 11 +
drivers/net/wireless/b43/dma.c | 21 +-
drivers/net/wireless/b43/main.c | 42 ++-
drivers/net/wireless/b43/phy_common.c | 9 +-
drivers/net/wireless/b43/phy_common.h | 5 +
drivers/net/wireless/b43/phy_lp.c | 94 ++++-
drivers/net/wireless/b43/phy_lp.h | 11 +-
drivers/net/wireless/b43/phy_n.c | 3 +-
drivers/net/wireless/b43/pio.c | 2 +-
drivers/net/wireless/b43legacy/dma.c | 22 +-
drivers/net/wireless/b43legacy/main.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 14 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 48 ++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 51 +--
drivers/net/wireless/iwlwifi/iwl-core.c | 6 -
drivers/net/wireless/iwlwifi/iwl-core.h | 3 +
drivers/net/wireless/iwlwifi/iwl-csr.h | 10 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 17 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
drivers/net/wireless/iwlwifi/iwl-rx.c | 1 -
drivers/net/wireless/iwlwifi/iwl-sta.c | 1 -
drivers/net/wireless/iwlwifi/iwl-tx.c | 1 +
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 9 +-
drivers/net/wireless/iwmc3200wifi/commands.c | 49 ++-
drivers/net/wireless/libertas/if_spi.c | 2 +-
drivers/net/wireless/libertas/wext.c | 2 +
drivers/net/wireless/orinoco/cfg.c | 41 ++
drivers/net/wireless/p54/led.c | 5 +-
drivers/net/wireless/p54/main.c | 2 +-
drivers/net/wireless/p54/p54spi.c | 4 +-
drivers/net/wireless/p54/txrx.c | 2 +-
drivers/net/wireless/rndis_wlan.c | 617 +++++++++++++++++++++---
drivers/net/wireless/rt2x00/Kconfig | 8 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 22 +-
drivers/net/wireless/rt2x00/rt61pci.c | 5 +
drivers/net/wireless/rtl818x/rtl8187_dev.c | 2 +-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 10 +-
drivers/net/wireless/strip.c | 9 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 2 +-
include/linux/rfkill.h | 1 +
include/linux/usb/rndis_host.h | 13 +-
include/linux/usb/usbnet.h | 6 +-
include/net/cfg80211.h | 14 -
include/net/mac80211.h | 58 ++-
net/mac80211/driver-trace.c | 3 +
net/mac80211/ibss.c | 6 +-
net/mac80211/ieee80211_i.h | 9 +-
net/mac80211/iface.c | 36 ++-
net/mac80211/main.c | 40 ++-
net/mac80211/mesh.c | 10 +-
net/mac80211/mesh_hwmp.c | 4 +-
net/mac80211/mlme.c | 113 +++--
net/mac80211/pm.c | 8 +-
net/mac80211/scan.c | 8 +-
net/mac80211/tx.c | 2 +-
net/mac80211/util.c | 41 ++
net/rfkill/core.c | 4 +-
net/wireless/core.c | 24 +-
net/wireless/core.h | 8 +-
net/wireless/mlme.c | 38 +-
net/wireless/reg.c | 107 ++---
net/wireless/reg.h | 15 +
net/wireless/sme.c | 55 ++-
net/wireless/wext.c | 1 -
96 files changed, 2757 insertions(+), 796 deletions(-)
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-08-06.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Fabio Comolli @ 2009-08-06 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA,
Rafael J. Wysocki, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090806183247.GI26809-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Hi John. I'm using ath5k .
The card is a:
01:00.0 Ethernet controller: Atheros Communications Inc. AR5001
Wireless Network Adapter (rev 01)
with PCI ID:
01:00.0 0200: 168c:001c (rev 01)
Regards,
Fabio
On Thu, Aug 6, 2009 at 8:32 PM, John W. Linville<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> What driver are you using?
>
> On Thu, Aug 06, 2009 at 08:30:23PM +0200, Fabio Comolli wrote:
>> Just got this after a resume from suspend-to-ram. Wifi needed to be
>> disabled and reenabled (with hardware Fn+F2 key - this is an eeePC900)
>> to function again.
>>
>>
>> [ 919.858759] ------------[ cut here ]------------
>> [ 919.858787] WARNING: at net/mac80211/mlme.c:2292
>> ieee80211_sta_work+0x97/0xd2d [mac80211]()
>> [ 919.858791] Hardware name: 900
>> [ 919.858793] Modules linked in: uvcvideo videodev v4l1_compat arc4
>> ecb ath5k mac80211 ath cfg80211
>> [ 919.860022] Pid: 793, comm: phy0 Tainted: G M 2.6.31-rc5 #11
>> [ 919.860025] Call Trace:
>> [ 919.860035] [<c10209cf>] warn_slowpath_common+0x65/0x7c
>> [ 919.860058] [<f83d621e>] ? ieee80211_sta_work+0x97/0xd2d [mac80211]
>> [ 919.860064] [<c10209f3>] warn_slowpath_null+0xd/0x10
>> [ 919.860086] [<f83d621e>] ieee80211_sta_work+0x97/0xd2d [mac80211]
>> [ 919.860092] [<c101bb2b>] ? __wake_up+0x2f/0x56
>> [ 919.860097] [<c101bb39>] ? __wake_up+0x3d/0x56
>> [ 919.860103] [<c102eb04>] ? insert_work+0x96/0x9f
>> [ 919.860108] [<c102ed63>] ? __queue_work+0x32/0x49
>> [ 919.860113] [<c102eda1>] ? queue_work_on+0x27/0x2f
>> [ 919.860119] [<c102f52f>] ? queue_work+0x2d/0x45
>> [ 919.860140] [<f83d3324>] ?
>> ieee80211_ibss_notify_scan_completed+0x63/0x68 [mac80211]
>> [ 919.860162] [<f83d1059>] ? ieee80211_scan_completed+0x320/0x328 [mac80211]
>> [ 919.860184] [<f83d1160>] ? ieee80211_scan_work+0xb5/0x171 [mac80211]
>> [ 919.860190] [<c102f075>] worker_thread+0x15d/0x204
>> [ 919.860211] [<f83d6187>] ? ieee80211_sta_work+0x0/0xd2d [mac80211]
>> [ 919.860218] [<c1032217>] ? autoremove_wake_function+0x0/0x2f
>> [ 919.860223] [<c102ef18>] ? worker_thread+0x0/0x204
>> [ 919.860229] [<c1031fab>] kthread+0x63/0x68
>> [ 919.860234] [<c1031f48>] ? kthread+0x0/0x68
>> [ 919.860240] [<c1002f93>] kernel_thread_helper+0x7/0x10
>> [ 919.860244] ---[ end trace 7a3a8d08c5a7bedf ]---
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Luis R. Rodriguez @ 2009-08-06 19:32 UTC (permalink / raw)
To: Fabio Comolli
Cc: John W. Linville, Linux Kernel Mailing List, netdev,
Rafael J. Wysocki, linux-wireless
In-Reply-To: <b637ec0b0908061226m33203bco7ac38cecb939b382@mail.gmail.com>
On Thu, Aug 6, 2009 at 12:26 PM, Fabio Comolli<fabio.comolli@gmail.com> wrote:
> Hi John. I'm using ath5k .
>
> The card is a:
>
> 01:00.0 Ethernet controller: Atheros Communications Inc. AR5001
> Wireless Network Adapter (rev 01)
>
> with PCI ID:
>
> 01:00.0 0200: 168c:001c (rev 01)
What kernel?
This is probably a driver/mac80211 adding work into the mac80211
workqueue during the susend --> resume cycle. We recently changed the
warning to be moved onto the actual caller who does the queue_work()
so we don't have to guess at this and do a painful debugging.
I suspect you are not using the latest wireless-testing.
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-08-06
From: David Miller @ 2009-08-06 20:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090806190200.GJ26809@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 6 Aug 2009 15:02:00 -0400
> Here is another big round of updates intended for 2.6.32...mostly the usual
> suspects, although it looks like Luis has been exceptionally busy with
> both ath9k and regulatory enforcement bits. Jussi has a number of
> rndis_wlan changes, and of course Johannes has a number of patches as
> well.
Pulled, thanks John.
Will push out to kernel.org after build tests.
^ permalink raw reply
* Re: [PATCH] netrom: Fix nr_getname() leak
From: David Miller @ 2009-08-06 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4A7ADB1B.2040401@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Aug 2009 15:31:07 +0200
> nr_getname() can leak kernel memory to user.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] rose: Fix rose_getname() leak
From: David Miller @ 2009-08-06 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4A7ADBCE.2040501@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Aug 2009 15:34:06 +0200
> rose_getname() can leak kernel memory to user.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] econet: Fix econet_getname() leak
From: David Miller @ 2009-08-06 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4A7ADF34.40703@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Aug 2009 15:48:36 +0200
> econet_getname() can leak kernel memory to user.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH] irda: Fix irda_getname() leak
From: David Miller @ 2009-08-06 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4A7AE0B8.8010600@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Aug 2009 15:55:04 +0200
> irda_getname() can leak kernel memory to user.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292 ieee80211_sta_work+0x97/0xd2d [mac80211]()
From: Fabio Comolli @ 2009-08-06 20:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Linux Kernel Mailing List, netdev,
Rafael J. Wysocki, linux-wireless
In-Reply-To: <43e72e890908061232k467ba1f7iece5d0aa9bece811@mail.gmail.com>
Hi Luis.
I'm using 2.6.31-rc5 and I'm not using wireless-testing.
Regards,
Fabio
On Thu, Aug 6, 2009 at 9:32 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Aug 6, 2009 at 12:26 PM, Fabio Comolli<fabio.comolli@gmail.com> wrote:
>> Hi John. I'm using ath5k .
>>
>> The card is a:
>>
>> 01:00.0 Ethernet controller: Atheros Communications Inc. AR5001
>> Wireless Network Adapter (rev 01)
>>
>> with PCI ID:
>>
>> 01:00.0 0200: 168c:001c (rev 01)
>
> What kernel?
>
> This is probably a driver/mac80211 adding work into the mac80211
> workqueue during the susend --> resume cycle. We recently changed the
> warning to be moved onto the actual caller who does the queue_work()
> so we don't have to guess at this and do a painful debugging.
>
> I suspect you are not using the latest wireless-testing.
>
> Luis
>
^ permalink raw reply
* Re: [PATCH 1/5] tc35815: Disable StripCRC
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-1-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:45 +0900
> It seems Rx_StripCRC cause trouble on recovering from the BLEx (Buffer
> List Exhaust) or FDAEx (Free Descriptor Area Exhaust) condition.
> Do not use it.
>
> Also bump version number up.
>
> Reported-by: Ralf Roesch <ralf.roesch@rw-gmbh.de>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/5] tc35815: Improve BLEx / FDAEx handling
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-2-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:46 +0900
> Clear Int_BLEx / Int_FDAEx after (not before) processing Rx interrupt.
> This will reduce number of unnecessary interrupts.
> Also print rx error messages only if netif_msg_rx_err() enabled.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 3/5] tc35815: Increase timeout for mdio
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-3-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:47 +0900
> The current timeout value is too short for very high-load condition
> which jiffies might jump up in busy-loop.
> Also add minimum delay before checking completion of MDIO.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 4/5] tc35815: Fix rx_missed_errors count
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-4-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:48 +0900
> The Miss_Cnt register is cleared by reading. Accumulate its value to
> rx_missed_errors count.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 5/5] tc35815: Use 0 RxFragSize.MinFrag value for non-packing mode
From: David Miller @ 2009-08-06 20:17 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-5-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:49 +0900
> The datasheet say "When not enabling packing, the MinFrag value must
> remain at 0". Do not set value to RxFragSize register if
> TC35815_USE_PACKEDBUFFER disabled.
>
> This is not a bugfix. No real problem reported on this.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox