This patch implements the draft spec: http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt At the moment, this is just an [RFC] patch because an option number hasn't been assigned by the IETF yet. It allows listening sockets to be configured with a small (<= 64 bytes), payload that is included in SYN/ACK packets elicited by SYN packets that include a special option. See the draft linked to above for motivations. Additionally, the listening socket can request that the kernel ...

Add another field to smc91x_platdata to configure LEDs. Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net> --- drivers/net/smc91x.c | 7 ++++++- drivers/net/smc91x.h | 5 ++++- include/linux/smc91x.h | 17 +++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index 2040965..a591508 100644 --- a/drivers/net/smc91x.c +++ b/drivers/net/smc91x.c @@ -1520,7 +1520,7 @@ smc_open(struct net_device *dev) ...

Hard data first, and then there will be plenty of time for blame later. Not that there's any real blame for anyone here, we just have a His commit may have uncovered a latent problem somewhere else, that happens often. But if the commit really is the trouble one, then two things happen: It's rc3 or rc4 now, so we just revert the damn thing, and then (secondly) he works with you (by adding debugging or whatever) to figure out where the problem actually is. The point I'm trying to make ...

[Empty message]

Could do I guess. Index: linux-2.6/mm/slub.c =================================================================== --- linux-2.6.orig/mm/slub.c +++ linux-2.6/mm/slub.c @@ -1543,7 +1543,7 @@ load_freelist: if (unlikely(!object)) goto another_slab; if (unlikely(PageSlubDebug(c->page) || c->reserve)) - goto debug; + goto slow_path; c->freelist = object[c->offset]; c->page->inuse = c->page->objects; @@ -1586,11 +1586,21 @@ grow_slab: goto load_freelist; } return ...

Oh yes, obvious when you explain it, thanks. cat << END >> Changelog As the test - if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))) - && !in_interrupt()) { - if (!(gfp_mask & __GFP_NOMEMALLOC)) { has been replaced with a slightly strong + if (alloc_flags & ALLOC_NO_WATERMARKS) { we need to ensure we don't recurse when PF_MEMALLOC is set END ?? Thanks, NeilBrown --

Pretty pointless yes, except that it made ___kmalloc_reserve a nicer function to read, and as its an utter slow path I couldn't be arsed to Hmm, that would be __mem_reserve_charge() then, because the callers Uhmm,. good point. Let me ponder this while I go for breakfast ;-) --

I'm not sure that this is really a good idea. If anything then tries to expand the head of this skb, they may fail and be forced to drop the packet. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

against __mem_reserve_charge(), granted, the race would be minimal at weirdness in my brain when I wrote that I guess, shall ammend! --

This looks suspiciously like debugging code that you have left in. This sort of thing always worries me. It is a per-cpu data structure so you won't get SMP races corrupting fields. But you do get read-modify-write in place of simple updates. I guess it's not a problem.. But it worries me :-) NeilBrown --

This patch all looks "obviously correct" and a nice factorisation of I don't remember seeing it before (though my memory is imperfect) and it doesn't seem to fit with the rest of the patch (except spatially). There is a test above for PF_MEMALLOC which will result in a "goto" somewhere else unless "in_interrupt()". There is immediately above a test for "!wait". So the only way this test can fire is when in_interrupt and wait. But if that happens, then the might_sleep_if(wait) at the top ...

Using Linux 2.6.23 I want to create multiple Vlans for voice, data, video etc. The requirement is to prioritize each vlan on the ingress and egress. I am looking at qdisc to do this however without success. Could you please advise is there is a way to do this using qdisc tc(traffic control) commands. If not - is there another way to do this in Linux ? Any help would be greatly appreciated. Thanks, Pravin --

On Mon, 11 Aug 2008 17:48:22 -0700 For 2.6.25, an addition to the tc meta match to allow matching on vlan tag was added. Using this it is possible to use meta match to convert tag -> flowid then use the flowid with a priority (or htb) queue. --

Also possible. But I guess I was thinking too complicated last night. What I was after with the "protect the whole ip_vs_lblc_schedule() with write_lock()ing the lock" was also to simply prevent someone adding duplicate entries. If we just extend the read_lock() region to cover the whole usage of the entry and do an additional duplicate check during inserting the entry under write_lock(), we fix the issue and also fix the race that someone may add duplicate entries. We have a bit ...

Hi Jeff, also in this patch, you have unresolved merge conflicts. Please see my other email on hints on resolving this. Best Regards Ingo Oeser --

From: Sven Wegener <sven.wegener@stealer.net> Pulled, thanks a lot Sven. --

From: Jarek Poplawski <jarkao2@gmail.com> The qdisc pointer traverses to the softirq handler, which can be run in a process context (via ksoftirqd), and this pointer gets there I didn't see it possible to keep scheduling the netdev_queues, as the qdiscs can be shared with multiple queues. Qdisc "are we running?" and other state pieces are now inside of the Qdisc itself. And all of the qdisc_run() and netif_schedule logic is, as a result, Qdisc centric. The synchronization object is the ...

On Tue, Aug 12, 2008 at 01:15:10AM -0700, David Miller wrote: If you mean net_tx_action() this looks like we would get a root lock of a current qdisc, just like seen in dev_queue_xmit() at the moment, so I'm still looking for a clue, what could be wrong with this... Jarek P. --

So, since it's currently impossible, here is an alternative solution. Jarek P. ------------> pkt_sched: Protect gen estimators under est_lock. gen_kill_estimator() required rtnl_lock() protection, but since it is moved to an RCU callback __qdisc_destroy() let's use est_lock instead. Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> --- net/core/gen_estimator.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/net/core/gen_estimator.c ...

From: Jarek Poplawski <jarkao2@gmail.com> Those comments are out of date and I need to update them. In fact this whole loop is now largely pointless. The rcu_dereference() on dev_queue->qdisc happens before the QDISC_RUNNING bit is set. We no longer resample the qdisc under any kind of lock. Because we no longer have a top-level lock that synchronizes the setting of dev_queue->qdisc Rather, the lock we use for calling ->enqueue() and ->dequeue() is inside of the root qdisc ...

If I get the time I will try to do that. Another way to understand why we are accepting the regressions here may be that we give more consideration to real time issues and deterministic performance these days. Hardware speed gains compensate for the additional bloat? (I ran the old kernels on cutting edge hardware after all). --

From: Gerrit Renker <gerrit@erg.abdn.ac.uk> Applied, thanks Gerrit. --

Actually, I just forgot earlyprintk=...,keep. Now I modified the printk() to use early_printk() if oops_in_progress is set. This does actually give some result, but again the text is garbled, this time for real, and I don't understand why. But this is what I get on the serial console: <0>BUG: NMI Watchdog detected LOCKUP on CPU1, ip c010ae8c, registers: Pid: 0, comm: swapper Not tainted (2.6.27-rc2-00325-g796aade-dirty #3) EIP: 0060:[<c010ae8c>] EFLAGS: 00000246 CPU: 1 EIP is at ...

It turns out that we're not getting as far as the "panic:" line in panic(). So I tried something new: Running a bash busy loop while unplugging the cable: $ while true; do echo p > /proc/sysrq-trigger; done And to my great surprise, the kernel doesn't reboot. But I can't use it either. It's simply printing the same message to ttyS0 over and over: SysRq : Show Regs It is also occasionally garbled, like this: SysRq : ow Regs ... Sys : Show Regs ... ...

Hi Luis, On Mon, 11 Aug 2008 09:46:57 -0700 "Luis R. Rodriguez" <lrodriguez@atheros.= That is only the first application of the patch, my patch is a fix of a second instance of the same code. See Adrian's post. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

From: Rick Jones <rick.jones2@hp.com> IP header is a little different, intermediate nodes should verify it (and we do adjust it when decrementing TTL). --

Yep. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

Well I wasn't suggesting that it be dropped, but simply skip LRO if the inbound packet fails the checksum check. But yeah, it's only two bytes so we might as well always have it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

Oh I totally agree that there are lots of scenarios where you want to have an unmolested guest image. My point was that if you're going to touch the guest kernel anyway you might as well fix the guest user-space instead. This is also why I've argued that the default should be to disable TX checksums until the guest enables it so that old guests that know nothing about this can continue to work. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} ...

Then should we insist the user set PACKET_AUXDATA? Even then, the format of that cmsg will have to be enhanced as we change kernel internals. Which is probably why you *don't* get to see the bare details: you get a flag saying "oh, I know the checksum is bad". Without the csum_start/csum_offset fields you can't even calculate what it will be. The dhcp client thing is a symptom which can be fixed, but are we doing the right thing? (Tho for lguest this is a new problem with the current ...

Are you talking about modifying the KVM client image? There may be reasons, why this is impossible or at least highly undesired. Before virtualisation developers of embedded stuff need to seal away their whole machines for their development and test environment together with sample hardware. Now using virtualisation they can at least virtualize their development and test environment, save lots of cost and not risking that their sealed away hardware will not start again, when they need to ...

Grrr. It looks like I was bitten by the infamous Netlink "No buffer space available" error which I was somehow overlooked. Applying your patch to a kernel which boots without the Netlink buffer space error shows the right output. Closing. Thanks. --

# ip -f inet6 route get fec0::1 unreachable fec0::1 dev lo table unspec proto none src 2001:1890:1109:a10:218:feff:fe7f:49c8 metric -1 error -101 hoplimit 255 And if I down eth0 I get: # ip -f inet6 route get fec0::1 unreachable fec0::1 dev lo table unspec proto none src ::1 metric -1 error -101 hoplimit 255 This is 2.6.27-rc2, like I said, I"m building a 2.6.24 kernel now. -Brian --

Just an fyi I think part of the confusion was the output I posted: # ip -f inet6 route get fec0::1 unreachable fec0::1 dev lo table unspec proto none src 2001:1890:1109:a10:218:feff:fe7f:49c8 metric -1 error -101 hoplimit 255 On my system I have a global address on eth0, so that's printed in my output. Others don't have a global, so see ::1, which is expected. I see the same behavior on my Debian Lenny 2.6.18 box as 2.6.27, so my patch doesn't seem to have changed ...

From: "Eugene Teo" <eugeneteo@kernel.sg> Hmmm... from what I understand so far based upon Parag's most recent reply, Brian's patch should be OK. Does everyone else agree? --

Folks I've enclosed patch from Eugene just so we all know which patch we're talking about. It 'works' according to the following definition: a) Fixed OOPS b) runs overnight in our test network. This run doesn't do much specific ipv6 testing - but clearly what's there is catching stuff :-; cheers John -----Original Message----- From: Eugene Teo [mailto:eugeneteo@kernel.sg]=20 Sent: 11 August 2008 12:04 To: Brian Haley Cc: Alexey Dobriyan; John Gumb; ...

Ok, so there's a mistake in my patch. It should return the loopback MAC address instead. I'm wondering if the fix should be related to initialising rt6i_idev in addrconf_init routine like in the upstream commit: c62dba9011b93fd88fde929848582b2a98309878. The code changed quite a lot. Eugene --

Acked-by: Brian Haley <brian.haley@hp.com> But Yoshfuji might have another opinion since he did the work to remove ipv6_get_saddr() in the first place. -Brian --

Right, well at least VIA could still use this and it wouldn't hurt others that much. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

* Works fine, machine is up since 61 minutes. * Performance: Routing performance over esp-tunnels seems unchanged here compared to 2.6.25 (this was also the case with the "kernel_fpu_begin" patch). tcrypt mode=200 shows exactly the same performance penalty compared to 2.6.25 as the "kernel_fpu_begin" patch. But I think this the right way to go with 2.6.26 und probably 2.6.27. And I'm not sure if tcyrpt really shows the whole story for 2.6.25: a) does it measure the costs of the ...

Yes, I'll test that tomorrow. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München Tel: +49 89 38196-276 Fax: +49 89 38196-144 wolfgang.walter@stwm.de http://www.studentenwerk-muenchen.de/ --

That's not sufficient, though, because you have to track all the state and how it relates to everything. You now have to track both the userspace FPU state and the potential kernel FPU state. The VIA instructions are special (in the short bus to school sense) in that they use a mechanism intended to protect specific state to protect -- exactly nothing. -hpa --

No, there you are actually using the FPU state (which includes the SSE state.) -hpa --

When one of these "hick-ups" happen while I am streaming video from my Myth backend to my Myth frontend, it kills the playback, and I have to re-start it. It takes 5 to 10 seconds before I can re-start the playback, but it does work without having to take any special action on my part. So, to answer your question, yes traffic does flow afterwards. John --

David Madsen <david.madsen@gmail.com> : Please note that the kernel complains more loudly about the watchdog than it used to. Does it allow traffic to flow afterwards ? -- Ueimor --

The usual problem with re-reading in a separate read-side critical section is that someone might have removed/destroyed it in the meantime. Consider the following example: Task 0: rcu_read_lock(); p = rcu_dereference(global_pointer); if (p == NULL) { rcu_read_unlock(); goto somewhere_else; } do_something_with(p); rcu_read_unlock(); do_some_unrelated_stuff(); rcu_read_lock(); do_something_else_with(p); /* BUG!!! */ rcu_read_unlock(); somewhere_else: Task ...

Sure, but I'm concerned here with pure RCU reading: From net/sched/sch_generic.c: void __qdisc_run(struct Qdisc *q) { unsigned long start_time = jiffies; while (qdisc_restart(q)) { /* * Postpone processing if * 1. another process needs the CPU; * 2. we've been doing it for too long. */ if (need_resched() || jiffies != start_time) { ...

OK, in that case you would not need the NULL check and goto, but Good point -- even if it were impossible in the current implementation, RCU is certainly within its rights to do the kfreeing in between. So Fair enough! Thanx, Paul --

From: Divy Le Ray <divy@chelsio.com> So, WHAT?! There are TOE pieces of crap out there too. It's strictly not our problem. Like Herbert said, this is the TOE discussion all over again. The results will be the same, and as per our decisions wrt. TOE, history speaks for itself. --

From: Steve Wise <swise@opengridcomputing.com> When I say shape I mean apply any packet scheduler, any netfilter module, and any other feature we support. --

On Tue, Aug 12, 2008 at 02:31:40PM +0300, Denys Fedoryshchenko wrote: Great! I didn't expect it would be so easy with this strange problem. So, it looks like hrtimers could break probably after some overscheduling. The only problem with this is to find some reasonable limit which is both safe and doesn't harm resolution too much for others. IMHO this second patch with 1 jiffie watchdog resolution looks reasonable and should be acceptable, but it would be nice to check if we can go lower. ...

In that case, let's add Lennert to the CC line. -- Martin Michlmayr http://www.cyrius.com/ --

From: Thomas Jarosch <thomas.jarosch@intra2net.com> We had the same situation with ECN and window scaling, and my proposal is the same as how we handled those situations involving broken middleware boxes. --

David, I agree with you, though I'm not sure about the end user experience: The kernel is an early adopter of FRTO and will be bitten by bugs of other TCP implementations like we've experienced. I guess most affected users just see stalled or slow connections and won't have the time or knowledge to debug this. A proper warning could help them and the kernel developers to get this issue solved as quickly as possible. We called the hotline of the ISP several times and they always ...