Keiichi KII wrote:
> From: Keiichi KII <[EMAIL PROTECTED]>
>
> This patch contains the following changes.
>
> create a sysfs entry for netconsole in /sys/class/misc.
> This entry has elements related to netconsole as follows.
> You can change configuration of netconsole(writable attributes such as
Back in Jan 2005, Stephen Hemminger added wake-on-lan support to the
skge driver -- cf. http://lwn.net/Articles/120679/
I'm unable to make it wake up from a powered-down state -- is this
expected to work? I have it working fine on an e1000 nic,
using the wakeonlan package --
$ wakeonlan -i 19
>
> > I investigated the ftp-file-transfer-stop problem by git-bisect method,
> > and found this problem was introduced by
> > "[TCP]: MD5 Signature Option (RFC2385) support" patch.
> >
> > Mr.YOSHIFUJI san, please fix this problem.
>
> Hmm, have you try disabling CONFIG_TCP_MD5SIG?
> (Is it al
In article <[EMAIL PROTECTED]> (at Sat, 30 Dec 2006 18:50:43 +0900), Komuro
<[EMAIL PROTECTED]> says:
> I investigated the ftp-file-transfer-stop problem by git-bisect method,
> and found this problem was introduced by
> "[TCP]: MD5 Signature Option (RFC2385) support" patch.
>
> Mr.YOSHIFUJI san
Hi,
I investigated the ftp-file-transfer-stop problem by git-bisect method,
and found this problem was introduced by
"[TCP]: MD5 Signature Option (RFC2385) support" patch.
Mr.YOSHIFUJI san, please fix this problem.
>commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
>Author: YOSHIFUJI Hideaki <[EMA
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Sat, 30 Dec 2006 08:36:07 +1100
> Heh, it's very possible it's a regression I added indeed. I'll try to
> have a look next week. Do you know of anybody who can verify on non-mii
> hardware or is pause irrelevant there ?
For PCS based PHY's mo
On Thu, 2006-12-28 at 21:05 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 13 Dec 2006 15:07:24 +1100
>
> > tg3 says
> >
> > tg3: eth0: Link is up at 1000 Mbps, full duplex.
> > tg3: eth0: Flow control is on for TX and on for RX.
> >
> > but sungem say
These two patches aren't in Linus tree yet:
http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029247.html
http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029248.html
They really need be in next release since mpx83xx ucc_geth driver
wont compile otherwise.
-
To unsubscribe from this li
The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
and mini-PCI-E cards. This patch implements a new routine to interrogate the
radio hardware enabled bit in the interface, logs the initial state and any
changes in the switch (if debugging enabled), activates the LED to sho
Hi Krzysztof,
On 12/29/06, Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
On Wed, 27 Dec 2006, jamal wrote:
> On Wed, 2006-27-12 at 09:09 +0200, Robert Iakobashvili wrote:
>
>>
>> My scenario is treatment of RTP packets in kernel space with a single network
>> card (both Rx and Tx). The default
On Fri, Dec 29, 2006 at 05:35:27PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> * netfilter netchannel backend (only NAT is supported as the most interesting
> user, NAT caches appropriate route, so essentially routing becomes part
> of the netchannel trie)
Source NAT example:
connct
Hi Stephen
I just wanted to ask you, if you already had time to test our trace
extension for netem as discussed on the 13th of December.
Cheers
Rainer
Rainer Baumann wrote:
> Hi Stephen
>
> As discussed yesterday, here our patches to integrate trace control into netem
>
>
>
> Trace Control for N
> Roy Marples (1):
> prism54: set carrier flags correctly
Why is this not #upstream-fixes material? What's the impact?
Actually, I think the patch is incorrect.
At best it is insufficient and at worst it
stops the driver working correctly.
I can't see why we do carrier_off after start
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > (rarer things like mouse/input events can stay with poll
> > notifications)
> >
> > and it is /especially/ important to include block IO events in
> > kevents to be able to judge its performance and scalability relative
> > to the async IO API
On Fri, Dec 29, 2006 at 01:54:27PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > > > Generic event handling mechanism.
> > >
> > > i see it covers alot of event sources, but i cannot see block IO
> > > notifications. Am i missing something?
> >
> > Depending on what it is :) If you mean keve
Hi all,
I have been comparing routing and bridging performance tests for
2.6.16,2.6.17,2.6.18,2.6.19 kernels.
The setup is:
eth0
| |
<-->|
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 28, 2006 at 05:01:37PM +0100, Ingo Molnar ([EMAIL PROTECTED])
> wrote:
> >
> > * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > > Generic event handling mechanism.
> >
> > i see it covers alot of event sources, but i cannot see
Private userspace notifications.
Allows to register notifications of any private userspace
events over kevent. Events can be marked as readt using
kevent_ctl(KEVENT_READY) command.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/kernel/kevent/kevent_unotify.c b/kernel/kevent/k
poll/select() notifications.
This patch includes generic poll/select notifications.
kevent_poll works simialr to epoll and has the same issues (callback
is invoked not from internal state machine of the caller, but through
process awake, a lot of allocations and so on).
Signed-off-by: Evgeniy Po
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentially eny kind of events.
Ev
Signal notifications.
This type of notifications allows to deliver signals through kevent queue.
One can find example application signal.c on project homepage.
If KEVENT_SIGNAL_NOMASK bit is set in raw_u64 id then signal will be
delivered only through queue, otherwise both delivery types are use
Pipe notifications.
diff --git a/fs/pipe.c b/fs/pipe.c
index 68090e8..0c75bf1 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -313,6 +314,7 @@ redo:
break;
}
if
Description.
diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt
new file mode 100644
index 000..95cb36e
--- /dev/null
+++ b/Documentation/kevent.txt
@@ -0,0 +1,244 @@
+Description.
+
+int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
+ unsigned int flags)
Socket notifications.
This patch includes socket send/recv/accept notifications.
Using trivial web server based on kevent and this features
instead of epoll it's performance increased more than noticebly.
More details about various benchmarks and server itself
(evserver_kevent.c) can be found on
Kevent posix timer notifications.
Simple extensions to POSIX timers which allows
to deliver notification of the timer expiration
through kevent queue.
Example application posix_timer.c can be found
in archive on project homepage.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git
Timer notifications.
Timer notifications can be used for fine grained per-process time
management, since interval timers are very inconvenient to use,
and they are limited.
This subsystem uses high-resolution timers.
id.raw[0] is used as number of seconds
id.raw[1] is used as number of nanosec
On Wed, Dec 27, 2006 at 08:16:10AM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Fri, Dec 22, 2006 at 06:05:18AM -0800, Ben Greear wrote:
> >>Jarek Poplawski wrote:
> >>>On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote:
> On 20-12-2006 03:13, Ben Greear wrote:
> >Th
On Thu, Dec 28, 2006 at 05:01:37PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > Generic event handling mechanism.
>
> i see it covers alot of event sources, but i cannot see block IO
> notifications. Am i missing something?
Depending on
On Thu, Dec 28, 2006 at 04:56:45PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > Generic event handling mechanism.
>
> it would be /very/ helpful to state against which kernel tree the
> patch-queue is. It does not apply to 2.6.20-rc1 nor
29 matches
Mail list logo
