On Tue, May 30, 2006 at 11:26:26PM -0700, David Miller wrote:
>
> I don't think it will be worthwhile to keep NAPI around just for
> TX completion. Sure the dev_kfree_skb() will schedule software
> interrupt work to do the actual free, but the TX ring walking
> and dev_kfree_skb() calls will be i
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 31 May 2006 15:14:51 +1000
> On Tue, May 30, 2006 at 10:11:17PM -0700, David Miller wrote:
> >
> > It will come back when net channels arrive :-) This is because net
> > channel drivers will do all the work in hard IRQs and not in a NAPI or
> > NAPI
On Wed, May 31, 2006 at 07:50:32AM +0200, Manfred Spraul wrote:
> Hi Willy,
>
> Willy Tarreau wrote:
>
> >I started from the latest backport you sent in september (0.42) and
> >incrementally applied 2.6 updates. I stopped at 0.50 which provides
> >VLAN support, because after this one, there are s
Hi Willy,
Willy Tarreau wrote:
I started from the latest backport you sent in september (0.42) and
incrementally applied 2.6 updates. I stopped at 0.50 which provides
VLAN support, because after this one, there are some 2.4-incompatible
changes (64bit consistent memory allocation for rings, and
On Tue, May 30, 2006 at 10:30:25PM -0700, Michael Chan wrote:
>
> I also don't see any problem. It looks like we don't have to set
> xmit_lock_owner, right?
Right, unless you want to call dev_queue_xmit recursively :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[E
David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 31 May 2006 14:58:11 +1000
>
> > Yes, TG3 does not disable IRQs when taking its TX lock. So do you
see
> > any problems with replacing the TG3 TX lock using xmit_lock?
>
> I don't see any.
>
I also don't see any problem.
On Tue, May 30, 2006 at 10:11:17PM -0700, David Miller wrote:
>
> It will come back when net channels arrive :-) This is because net
> channel drivers will do all the work in hard IRQs and not in a NAPI or
> NAPI-like context.
I thought the current channel stuff is RX only. Is TX completion movi
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 31 May 2006 14:58:11 +1000
> Hi Michael:
>
> On Tue, May 30, 2006 at 09:51:03PM -0700, Michael Chan wrote:
> >
> > > That's why I suggest that every NIC that uses this feature be forced
> > > to do what TG3 does so only BH disabling is needed. Once
Hi Michael:
On Tue, May 30, 2006 at 09:51:03PM -0700, Michael Chan wrote:
>
> > That's why I suggest that every NIC that uses this feature be forced
> > to do what TG3 does so only BH disabling is needed. Once that's done
> > they can just use xmit_lock and everyone will be happy again.
>
> As l
Herbert Xu wrote:
> On Tue, May 30, 2006 at 09:13:22PM -0700, David Miller wrote:
> > As per the bug, I always keep thinking about changing how we
> > do the lockless stuff by simply making xmit_lock a pointer.
> > Drivers like tg3 can make it point to their local driver lock.
>
> This is equival
On Tue, May 30, 2006 at 09:13:22PM -0700, David Miller wrote:
>
> There were numbers posted for real drivers at one point, I
> do remember that, and the gains were non-trivial. At least
> enough to justify the feature.
I wonder if there are other ways of achieving the same improvement.
> As per
Herbert> However, lockless drivers do not take the xmit_lock so
Herbert> this method is ineffective. Such drivers need to do
Herbert> their own checking inside whatever locks that they do
Herbert> take. For example, tg3 could get around this by checking
Herbert> whether the qu
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 31 May 2006 14:03:07 +1000
> I must say though that I'm becoming less and less impressed by the
> lockless feature based on the number of problems that it has caused.
> Does anyone have any hard figures as to its effectiveness (excluding
> any stats
Hi:
It has occured to me that the function netif_tx_disable may be unsafe
when used in drivers that do lockless transmission. In particular,
the function relies on taking the xmit_lock to ensure that no further
transmissions will occur until the queue is started again.
However, lockless drivers
* James Morris <[EMAIL PROTECTED]> 2006-05-27 13:21
> Actually, a possible solution here is to completely remove all internal
> knowledge of netlink messages from SELinux and have the netfilter
> framework and protocols provide methods to determine message types and
> permissions.
Right, regard
On Tue, May 23, 2006 at 05:20:13PM -0700, Chris Leech wrote:
> Adds a new ioatdma driver
>
> Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
> ---
>
> drivers/dma/Kconfig |9
> drivers/dma/Makefile|1
> drivers/dma/ioatdma.c | 839
> ++
The following changes since commit d9ec5ad24ce80b7ef69a0717363db661d13aada5:
Linus Torvalds:
Merge branch 'upstream-fixes' of
master.kernel.org:/.../jgarzik/libata-dev
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/tcp-2.6.git
Bin Zhou:
My test box running rc5-mm1 was kinda sitting there doing nothing when it
decided to have an oops in the llc code. See
http://www.zip.com.au/~akpm/linux/patches/stuff/dsc03542.jpg
gdb says:
0x197 is in llc_rcv (net/llc/llc_input.c:68).
63 static __inline__ int llc_pdu_type(struct sk_buf
As you know, we've said we were going to have a developer's program. You
can find more information, including how to apply for boards at:
http://wiki.laptop.org/index.php/Developers_Program
Note that these are bare PC prototype boards, not packaged machines.
Jim Gettys
Ivo van Doorn <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/input/misc/radiobtn.c b/drivers/input/misc/radiobtn.c
> new file mode 100644
> index 000..8d3b84a
> --- /dev/null
> +++ b/drivers/input/misc/radiobtn.c
[...]
> +void radiobtn_poll(unsigned long data)
static ?
[...]
> +int radiob
jesse\(??\) <[EMAIL PROTECTED]> :
[...]
> --Remove Threshold comfig and RxDMAInt from ipg_io_config(). Remove relative
> define form ipg.h
Na??ve question: why ?
Hardware assisted Rx irq mitigation is cool (TM).
> --Remove and Rewrite ipg_config_autoneg() function.
- Is there any hardware
To follow on from the previous 'sky2 rx error' problem reported, the
problem doesn't have anything to do with iptables or MTU settings, ie
can be reproduced out the box.
The race is hit after a couple of GBs of data. Initially, I thought
this may have something to do with broken MSI support on my
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 30 May 2006 15:48:38 +0400
> On Tue, May 30, 2006 at 01:34:02PM +0200, Andreas Schwab ([EMAIL PROTECTED])
> wrote:
> > There is no point in testing the atomic value if the result is thrown
> > away.
>
> It was created to put implicit smp barr
On Tue, May 30, 2006 at 02:58:11PM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> > Apache still can setup routes using ioctl or execve("ip route add/route
> > add");
>
> Depends on the policy. You can specify which types of files/sockets
> apache can perform ioctl on, and whether it can exec
On Tue, 30 May 2006, Evgeniy Polyakov wrote:
> On Tue, May 30, 2006 at 10:18:32AM -0400, James Morris ([EMAIL PROTECTED])
> wrote:
> > > And, btw, what is the purpose of controlling netlink messages?
> > > Does it prevent malicious userspace application to receive events from
> > > malicious kern
Hi Arjan,
On 30/05/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Tue, 2006-05-30 at 17:59 +0200, Michal Piotrowski wrote:
> Hi,
>
> On 30/05/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
> >
> >
Am Dienstag 30 Mai 2006 20:07 schrieb Ben Greear:
> May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on
> inter face eth2#18.IPv4 with address 172.1.2.20.
> May 30 11:01:37 x64-1u avahi-daemon[2022]: IP_ADD_MEMBERSHIP failed: No
> buffer s pace available
there is a configur
On Tue, May 30, 2006 at 10:18:32AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> > And, btw, what is the purpose of controlling netlink messages?
> > Does it prevent malicious userspace application to receive events from
> > malicious kernel module?
>
> It provides control over which types of
This is an FC5 64-bit system with 1GB RAM and dual-core Opteron.
When I create a bunch of virtual interfaces, I see this in
/var/log/messages. The kernel is 2.6.16.16 plus my hacks.
At first look, it doesn't appear I actually need the avahi tool, so
I'm just going to disable it. But, I thought
Since there seems to be lots of interest in TCP congestion control, here
is a cleaned up version of my TCP congestion tracker. I will put in the
TCP git tree for 2.6.18
This adds a new module for tracking TCP state variables non-intrusively
using kprobes. It has a simple /proc interface that
Attached are two small patches for include/net/ieee80211.h to prepare for later submission of code
to implement a user-space daemon that supplies 802.11 regulatory information.
The first change adds a bit indicating that 802.11h rules are to be applied to a channel. As
discussed earlier in this
On Tue, May 30, 2006 at 04:47:42PM +0200, Pavel Machek wrote:
> Hi!
>
> > > I see some strange problems with zd1201. (Ccing greg, he seen
> > > something similar).
> >
> > Which zd1201 driver are you using?
>
> In-tree one, 2.6.17-rc4 (and around). Ouch and I've "solved" the
> zaurus problme in
Hello!
> > static void netlink_table_grab(void)
> > {
> > write_lock_bh(&nl_table_lock);
>
> well it could be this one as well...
Indeed.
But it still looks as something very strange.
There are some GFP_KERNEL allocations on the way to this function.
-
To unsubscribe from this list: sen
On Tue, 2006-05-30 at 17:59 +0200, Michal Piotrowski wrote:
> Hi,
>
> On 30/05/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
> >
> >
>
> It looks like a network stack problem.
>
> May 30 17:50:34 ltg0
On Tue, 2006-05-30 at 20:00 +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > ok, that WARN_ON is over-eager. Fix is below:
>
> Nevertheless, I cannot figure out what's happening here.
>
> This local_bh_disable() is called right after schedule().
> No way irqs can be disabled there. What is wrong?
>
Hello!
> ok, that WARN_ON is over-eager. Fix is below:
Nevertheless, I cannot figure out what's happening here.
This local_bh_disable() is called right after schedule().
No way irqs can be disabled there. What is wrong?
static void netlink_table_grab(void)
{
write_lock_bh(&nl_table_loc
Hi,
On 30/05/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
It looks like a network stack problem.
May 30 17:50:34 ltg01-fedora init: Switching to runlevel: 6
May 30 17:50:35 ltg01-fedora avahi-daemon[18
On Út 30-05-06 16:11:02, Oliver Neukum wrote:
> Am Dienstag, 30. Mai 2006 15:20 schrieb Pavel Machek:
> > 2) usb problem, probably. Should not usb core detect that card
> > requires too much juice and refuse to power it up?
>
> Does your hub correctly report whether it is plugged in?
No idea; how
Hi!
> > I see some strange problems with zd1201. (Ccing greg, he seen
> > something similar).
>
> Which zd1201 driver are you using?
In-tree one, 2.6.17-rc4 (and around). Ouch and I've "solved" the
zaurus problme in the meantime -- it was hw one.
On Tue, May 30, 2006 at 01:17:12PM +0200, Pavel Machek wrote:
> Hi!
>
> I see some strange problems with zd1201. (Ccing greg, he seen
> something similar).
Which zd1201 driver are you using?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a me
On Mon, 29 May 2006, jamal wrote:
> If SELinux should provide ways to add "filters" more dynamically at its
> hooks - instead of having people go and look for that table and update
> it then it would simplify things and we may be able to easily have
> netlink users to register such filters at star
Am Dienstag, 30. Mai 2006 15:20 schrieb Pavel Machek:
> 2) usb problem, probably. Should not usb core detect that card
> requires too much juice and refuse to power it up?
Does your hub correctly report whether it is plugged in?
Regards
Oliver
-
To unsubscribe from this li
On Sun, 28 May 2006, Evgeniy Polyakov wrote:
> Does SELinux have security handlers for each type of possible ioctls
> over the world? Each ioctl number is like each netlink type of message,
> but instead there is only one check per ioctl syscall as long as lsm
> hook for socket's send/recv syscall
Hi!
Now I found out what went wrong with zd1201 on sharp zaurus (spitz)...
Card is detected and seems to work okay, except that you don't get any
results from iwlist eth1 scan, and card generally does not do anything
involving radio.
And now I have an explanation, too:
If you plug card directly
On Tue, May 30, 2006 at 01:34:02PM +0200, Andreas Schwab ([EMAIL PROTECTED])
wrote:
> There is no point in testing the atomic value if the result is thrown
> away.
It was created to put implicit smp barrier, but it is not needed there.
Your patch is correct, thank you.
> Signed-off-by: Andreas S
* Jiri Slaby <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
>
> BUG: warning at /l/latest/xxx/kernel/softirq.c:86/local_bh_disable()
ok, that
There is no point in testing the atomic value if the result is thrown
away.
Signed-off-by: Andreas Schwab <[EMAIL PROTECTED]>
diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 9f2f00d..05f8ce2 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.
Hi!
I see some strange problems with zd1201. (Ccing greg, he seen
something similar).
Wireless LAN is configured on eth1 (ipw2200) and works. I insert
zd1201 usb wireless card, and pings stop. I do not have (or should not
have) any hotplug scripts doing anything. Leds on zd1201 light up.
If I un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
BUG: warning at /l/latest/xxx/kernel/softirq.c:86/local_bh_disable()
[] show_trace+0x1b/0x1d
[] dump_stack+0x26/0x28
[] local_bh_dis
Hi Jesse,
On Tue, 30 May 2006, jesse\(??\)~H~H\) wrote:
> Sorry for that. I try to generate the patch file. But I only can use
> "diff -uN" to generate it. The "diff --git" is not work. I still try to
> generate it.
I assume you're using Francois' git tree, right? What you need to do is:
- Ch
On 25/05/06, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Daniel J Blueman wrote:
> On 25/05/06, Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>> Daniel, is there an easy way to reproduce the checksum failure?
>
> In short, no. This was seen when packets may have been truncated by
> large MTU (eg 90
Hi,
Seems that instead of clearing the confusion I was confused myself.
What we are talking about here is the protocol ID carried in the
ethernet header, which ethernet uses to identify the network layer (as
defined in the file ).
So its indeed IEEE to address for this, and not IANA.
Thanks f
Pavel Machek wrote:
Hi!
FLAME stands for "Forwarding Layer for Meshing"
FLAME provides an intermediate layer between the network
layer (e.g. IPv4/IPv6) and the link (MAC) layer,
providing L2.5 meshing. Both network layer and MAC layer
What is wrong with meshing on L3?
(It is cal
On Mon, 29 May 2006, Andrew Morton wrote:
> It takes people quite a few iterations to get patch preparation worked out.
>
> Pekka, if you have time, perhaps you can extract the patches for us?
Jesse, I wasn't able to work out the ipg_config_autoneg() changes, but the
rest of them are at:
http
Stephen Hemminger wrote:
Didn't you just reinvent 802.1d bridging? and/or WDS?
Hi Stephen,
Yes, more or less, but with a twist.
802.1D does not allow retransmitting over the same interface (which is
what basically happens in mesh networks), and WDS uses static
configuration of neighbou
55 matches
Mail list logo
