Re: Network activity LED trigger

On Fri, 2007-02-03 at 16:03 +, Richard Purdie wrote: > On Fri, 2007-03-02 at 10:16 -0500, jamal wrote: > We already have this API, see drivers/leds ;-) Very cool ;-> I was not aware of the existence of this API. Actually i dont think it was available around 2.6.10. > We have LEDs which show

Re: [git patches] net driver fixes

Linus Torvalds wrote: On Thu, 1 Mar 2007, Kok, Auke wrote: and lspci says: 00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02) DMI info isn't very interesting, but it's an all-Intel board: so it's all-intel chipset, all-intel board, and all-int

Re: [PATCH] NetLabel: Verify sensitivity level has a valid CIPSO mapping

On Wednesday, February 28 2007 3:01:31 pm Paul Moore wrote: > The current CIPSO engine has a problem where it does not verify that the > given sensitivity level has a valid CIPSO mapping when the "std" CIPSO DOI > type is used. The end result is that bad packets are sent on the wire > which should

Re: [git patches] net driver fixes

On Thu, 1 Mar 2007, Kok, Auke wrote: > Linus Torvalds wrote: > > > > Ok, here's an interesting one: my e1000 card no longer worked for a while. > > > > The green link-light blinks on/off once a second, and in time to that, my > > dmesg fills up with an endless supply of > > > > e1000: eth

Re: Network activity LED trigger

On Fri, 2007-03-02 at 10:16 -0500, jamal wrote: > Heres my view of what would be useful: > Have them accessible via the kernel, but also have an API from user > space. This way user space apps can control the LED, but if i wanted to > do it from the kernel i could as well. In my case i was actually

Re: [Bugme-new] [Bug 8107] New: dev->header_cache_update has a random value

Andrew Morton <[EMAIL PROTECTED]> writes: >> However, in >> drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct >> net_device *dev, struct ifreq *ifr), where dev->hard_header is assigned a >> valid >> function, and dev->hard_header_cache is assigned a known value (NULL), de

Re: Network activity LED trigger

On Fri, 2007-02-03 at 15:16 +0100, Florian Fainelli wrote: > Hi, > > Le vendredi 2 mars 2007, jamal a écrit : > > Where are these LEDs typically located? Are you talking about LEDs on a > > network card for example? can you light them up in different colors? > > Those LEDS are typically controlle

[PATCH] NET : convert network timestamps to ktime_t

We currently use a special structure (struct skb_timeval) and plain 'struct timeval' to store packet timestamps in sk_buffs and struct sock. This has some drawbacks : - Fixed resolution of micro second. - Waste of space on 64bit platforms where sizeof(struct timeval)=16 I suggest using ktime_t t

[PATCH 2/2] tc35815 driver update (part 2)

More updates for tc35815 driver, including: * TX4939 support. * NETPOLL support. * NAPI support. (disabled by default) * Reduce memcpy on receiving. * PM support. * Many cleanups and bugfixes. Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]> --- drivers/net/tc35815.c | 827 ++

Re: Network activity LED trigger

Hi, Le vendredi 2 mars 2007, jamal a écrit : > Where are these LEDs typically located? Are you talking about LEDs on a > network card for example? can you light them up in different colors? Those LEDS are typically controlled by GPIO lines visible in front of the device. It is mostly targeted to

Re: Network activity LED trigger

Where are these LEDs typically located? Are you talking about LEDs on a network card for example? can you light them up in different colors? cheers, jamal On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote: > Hi All, > > Some more thoughts. The IDE activity LED trigger is currently trigg

Re: [RFC] Arp announce (for Xen)

On Fri, 2007-02-03 at 13:54 +0100, Andi Kleen wrote: > Seems like the right solution to me (if it works) I like it as well given the simple change. These are the kind of optimizations that justify offloading things to the kernel (instead of user space) i.e very little lines of code, covers a lar

Re: [RFC] Arp announce (for Xen)

On Thu, Mar 01, 2007 at 05:30:30PM -0800, Stephen Hemminger wrote: > What about implementing the unused arp_announce flag on the inetdevice? > Something like the following. Totally untested... > > Looks like it either was there (and got removed) or was planned but > never implemented. Seems like

Re: Network activity LED trigger

Hi All, Some more thoughts. The IDE activity LED trigger is currently triggered when a function is called in the IDE writing/reading routines. In a similar way, we could call the trigger function in net/core/dev.c in netif_receive_skb and netif_rx ? I was also thinking that some network NIC al

[PATCH v2] [TCP]: FRTO undo response falls back to ratehalving one if ECEd

Undoing ssthresh is disabled in fastretrans_alert whenever FLAG_ECE is set by clearing prior_ssthresh. The clearing does not protect FRTO because FRTO operates before fastretrans_alert. Moving the clearing of prior_ssthresh earlier seems to be a suboptimal solution to the FRTO case because then FLA

[PATCH] [TCP]: FRTO undo response falls back to ratehalving one if ECEd

Undoing ssthresh is disabled in fastretrans_alert whenever FLAG_ECE is set by clearing prior_ssthresh. This clearing does not protect FRTO because FRTO operates before fastretrans_alert. Moving the clearing of prior_ssthresh earlier seems to be a suboptimal solution to the FRTO case because then FL

Re: s390 allmodconfig

On Fri, 02 Mar 2007 12:11:48 +0100 Johannes Berg <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-02 at 03:06 -0800, Andrew Morton wrote: > > > No, s390 doesn't have PCI. > > Ok. > > > s390 is weird ;) There's no way it'll support any of the hardware which > > you're > > working on (until they r

Re: s390 allmodconfig

On Fri, 2007-03-02 at 03:06 -0800, Andrew Morton wrote: > No, s390 doesn't have PCI. Ok. > s390 is weird ;) There's no way it'll support any of the hardware which > you're > working on (until they release the s390 laptop). So all we really want to > do here is to avoid breaking s390 allmodco

Re: s390 allmodconfig

On Fri, 02 Mar 2007 11:38:24 +0100 Johannes Berg <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote: > > > Probably related to the Kconfig problems. > > Yeah, it is. s390 is funny, it doesn't include drivers/Kconfig, I don't > think anybody of us would have suspe

Re: s390 allmodconfig

On Fri, 02 Mar 2007 10:32:32 + Richard Purdie <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote: > > net/mac80211/ieee80211_led.c: In function 'ieee80211_led_init': > > net/mac80211/ieee80211_led.c:38: error: invalid application of 'sizeof' to > > incomplete

Re: s390 allmodconfig

On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote: > Probably related to the Kconfig problems. Yeah, it is. s390 is funny, it doesn't include drivers/Kconfig, I don't think anybody of us would have suspected that. There doesn't seem to be a reason why it shouldn't have drivers/leds though.

Re: Extensible hashing and RCU

On Fri, Mar 02, 2007 at 10:56:23AM +0100, Eric Dumazet ([EMAIL PROTECTED]) wrote: > On Friday 02 March 2007 09:52, Evgeniy Polyakov wrote: > > > Ok, I've ran an analysis of linked lists and trie traversals and found > > that (at least on x86) optimized one list traversal is about 4 (!) > > times

Re: s390 allmodconfig

On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote: > net/mac80211/ieee80211_led.c: In function 'ieee80211_led_init': > net/mac80211/ieee80211_led.c:38: error: invalid application of 'sizeof' to > incomplete type 'struct led_trigger' > net/mac80211/ieee80211_led.c:43: error: dereferencing poi

Re: CLOCK_MONOTONIC datagram timestamps by the kernel

On Friday 02 March 2007 10:26, John wrote: > Eric Dumazet wrote: > > Anyway, if you want to play, you can apply this patch on top of > > linux-2.6.21-rc2 (nanosecond resolution infrastructure needs 2.6.21) > > I let you do the adjustments for rt kernel. > > Why does it require 2.6.21? Well, this

Re: [RFC] Arp announce (for Xen)

On 2/3/07 01:30, "Stephen Hemminger" <[EMAIL PROTECTED]> wrote: > What about implementing the unused arp_announce flag on the inetdevice? > Something like the following. Totally untested... > > Looks like it either was there (and got removed) or was planned but > never implemented. This would b

Re: Extensible hashing and RCU

On Friday 02 March 2007 09:52, Evgeniy Polyakov wrote: > Ok, I've ran an analysis of linked lists and trie traversals and found > that (at least on x86) optimized one list traversal is about 4 (!) > times faster than one bit lookup in trie traversal (or actually one > lookup in binary tree-like st

Re: CLOCK_MONOTONIC datagram timestamps by the kernel

Eric Dumazet wrote: John wrote: Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700). All this system does is time stamp 1000 packets per second. Are you claiming that this platform *cannot* handle most pa

Re: [PATCH 2.6.20] kobject net ifindex + rename

On Thu, Mar 01, 2007 at 11:27:34AM -0800, Jean Tourrilhes wrote: > On Thu, Mar 01, 2007 at 08:42:09AM +0100, Jarek Poplawski wrote: > > On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote: > > > > > + > > > > > + if ((size <= 0) || (i >= num_envp)) > > > > > > > > Btw.: > > > > 1.

Re: [RFC] Arp announce (for Xen)

On Thu, 1 Mar 2007, Stephen Hemminger wrote: What about implementing the unused arp_announce flag on the inetdevice? Something like the following. Totally untested... Looks like it either was there (and got removed) or was planned but never implemented. If something like this goes in, it woul

Re: need some help on a backport of r8169

[EMAIL PROTECTED] a écrit, le Thu 01 Mar 2007 à 10:57:11AM : > Hello Ueimor, > [...] > > Once you have logged the ifconfig/ethtool dump, you can try the serie > > or the patch at: > > > > http://www.fr.zoreil.com/people/francois/backport/r8169/20070228-00 > Hum... ok I might have enough time to c

Very slow routing table modification if RTA_FLOW is set

Hello all, I have noticed that using realm patch for quagga causes the kernel to spend a lot more time processing rtnetlink messages. If routes added to the kernel are not tagged with a realm number, the time from sending a netlink cmd to receiving a

Re: Extensible hashing and RCU

On Sat, Feb 17, 2007 at 04:13:02PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > > >I noticed in an LCA talk mention that apprently extensible hashing > > >with RCU access is an unsolved problem. Here's an idea for solving it. > > > > > > > Yes, I have been playing around with the sam

Re: s390 allmodconfig

net/mac80211/ieee80211_led.c: In function 'ieee80211_led_init': net/mac80211/ieee80211_led.c:38: error: invalid application of 'sizeof' to incomplete type 'struct led_trigger' net/mac80211/ieee80211_led.c:43: error: dereferencing pointer to incomplete type net/mac80211/ieee80211_led.c:44: warning

s390 allmodconfig

Not sure who to blame for all of this... net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP' refer to undefined symbol 'HID' net/mac80211/Kconfig:17:warning: 'select' used by config symbol 'MAC80211_LEDS' refer to undefined symbol 'NEW_LEDS' net/mac80211/Kconfig:18:wa

Re: [PATCH -mm 3/5] Blackfin: on-chip ethernet MAC controller driver

On Thu, 2007-03-01 at 10:52 -0500, Stephen Hemminger wrote: > > Please do not use mixed case for function or structure member names > (see > Coding Style) > Here is the updated version of this driver. a) Change to follow kernel coding style b) rename some functions and structures c) chang

<    1   2