Eric W. Biederman wrote:
Daniel Lezcano <[EMAIL PROTECTED]> writes:
[...]
* When do you expect to have the network namespace into mainline ?
My current goal is to finish my rebase against 2.6.linus_lastest in
the next couple of days after having figured out how to deal with sysfs.
Great ne
Kok, Auke wrote:
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp235
On 3/28/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Kok, Auke wrote:
Sounds sane to me. My overall opinion on eepro100 removal is that we're
not there yet. Rare problem cases remain where e100 fails but eepro100
works, and it's older drivers so its low priority for everybody.
Needs to happen, t
Steve Wise wrote:
On Wed, 2007-03-28 at 16:28 -0700, Mark Huth wrote:
Steve Wise wrote:
Hey all,
I have netpoll question. How does netpoll work with MSI/X, NAPI, and
nics that setup multiple RSS style receive queues for a single port?
>From what I can tell, if you're doing something l
Ok, this is what I was initially trying to do, pull out the
inner-most loop main code into a helper function.
Pushed to net-2.6.22
commit b096b50b4bf3c923bee28751d1ed41e92361a298
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Wed Mar 28 19:35:51 2007 -0700
[TCP]: Create tcp_sacktag_one
On Wed, 2007-03-28 at 16:28 -0700, Mark Huth wrote:
> Steve Wise wrote:
> > Hey all,
> >
> > I have netpoll question. How does netpoll work with MSI/X, NAPI, and
> > nics that setup multiple RSS style receive queues for a single port?
> > >From what I can tell, if you're doing something like netdu
From: Chris Snook <[EMAIL PROTECTED]>
Some atl1 boards get their MAC address written directly to the register
by the BIOS during POST, rather than storing it in EEPROM that's
accessible to the driver. If the MAC register on one of these boards
is changed and then the module is unloaded, the perma
It's nearly impossible to break out tcp_sacktag_write_queue() into
smaller worker functions because there are so many local variables
that are live and updated throughout the inner loop and beyond.
So create a state block so we can start simplifying this function
properly.
Pushed to net-2.6.22
On Wed, 2007-03-28 at 08:52 -0700, Stephen Hemminger wrote:
> It would make sense to do it per-cpu and 64 bit for the non-error counters.
Well, I looked at the e1000, it doesn't update on every packet anyway,
but seems to d/l from the card occasionally. I assume this is the
method for high-speed
Tried on 2.6.21-rc5-git3, but preempt enabled
Same panic, same place seems
Mar 29 02:50:53 LINUX [ 164.644102] BUG: unable to handle kernel paging
request
Mar 29 02:50:53 LINUX at virtual address 0302014c
Mar 29 02:50:53 LINUX [ 164.644242] printing eip:
Mar 29 02:50:53 LINUX [ 164.644301] *p
From: Chris Snook <[EMAIL PROTECTED]>
Add PCI ID for the Attansic L2 100 Mb ethernet adapter.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5.orig/include/linux/pci_ids.h 2007-03-27
23:26:50.0 -0400
+++ linux-2.6.21-rc5/include/linux/pci_ids.h2007-03-28 15:
I'm about to reattempt the hacks to make tcp_sacktag_write_queue()
use the RB tree lookups.
In order to make the changes easier to review I'm trying to clean
up the function a little bit. This one pulls out the DSACK
detection logic.
I'm starting to pepper get_unaligned() calls around the sack
Steve Wise wrote:
Hey all,
I have netpoll question. How does netpoll work with MSI/X, NAPI, and
nics that setup multiple RSS style receive queues for a single port?
>From what I can tell, if you're doing something like netdump using
netpoll for IO, then you might never process incoming packets
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp2350 works both with
Kok, Auke wrote:
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the
questions raised by Eric Piel or Kiszka. I do know that e10
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the questions
raised by Eric Piel or Kiszka. I do know that e100 didn't work on s
Reported to work on the WinFast 761GXK8MB-RS motherboard.
Plain 10/100 Mbps.
Signed-off-by: Paul Gibbons <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/sis190.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sis190.c b
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the questions
raised by Eric Piel or Kiszka. I do know that e100 didn't work on some
IBM rackmount ser
On Wed, Mar 28, 2007 at 02:55:56PM -0700, Jeremy Fitzhardinge wrote:
>
> Hm, I was wondering if there's a nicer way of getting the same result.
> Does it need to be done that way?
Actually you could use the skb->cb buffer which can store anything and
doesn't need to be cleaned up.
Cheers,
--
V
Hey all,
I have netpoll question. How does netpoll work with MSI/X, NAPI, and
nics that setup multiple RSS style receive queues for a single port?
>From what I can tell, if you're doing something like netdump using
netpoll for IO, then you might never process incoming packets that get
posted to t
Herbert Xu wrote:
> I've had a look at now and you can just stuff it into one of the other
> pointers that's still there. We just need to make sure that it is
> reset properly before we feed the packet into the stack. The pointer
> skb->dev is one candidate but there are plenty of others.
>
H
Hi Jeremy:
On Wed, Mar 28, 2007 at 11:36:17AM -0700, Jeremy Fitzhardinge wrote:
>
> I wonder if you've got a chance to look at netfront in light of the new
> stuff in davem's network tree (the stuff that's in
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.22.git).
I've had a look at
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 08:52:24 -0700
> It would make sense to do it per-cpu and 64 bit for the non-error
> counters.
Good point, but that's a seperate change.
I have no real objection to Rusty's change and if more than
one driver uses this thing it's
Jesse <[EMAIL PROTECTED]> :
[...]
> The latest version had been modified by you.
> Would you be kindly to do this for me.
I have just screwdriven a test machine but I will not finish a
build/test cycle today.
--
Ueimor
Anybody got a battery for my Ultra 10 ?
-
To unsubscribe from this list: se
From: James Morris <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 12:31:56 -0400 (EDT)
> On Wed, 28 Mar 2007, Eric Dumazet wrote:
>
> > Hello David
> >
> > We could use the nanosec resolution for various functions defined in
> > drivers/char/random.c
> > (secure_tcpv6_sequence_number(), secure_tcp_
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 13:57:18 -0800
> [BNX2]: Fix link interrupt problem.
>
> bnx2_has_work()'s logic is flawed and can cause the driver to miss
> a link event. The fix is to compare the status block's attn_bits
> and attn_bits_ack to determine if there
[BNX2]: Fix link interrupt problem.
bnx2_has_work()'s logic is flawed and can cause the driver to miss
a link event. The fix is to compare the status block's attn_bits
and attn_bits_ack to determine if there is a link event.
Update version to 1.5.6.
Signed-off-by: Michael Chan <[EMAIL PROTECTED
> In my patch the random seed is initialized when the first TCP or DCCP
> socket is created, at which point we'll have sufficient entropy.
See my discussion of this case in a later mail to Evgeniy
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
Do you have any pointer to help on benchmarking the network, perhaps a
checklist or some scripts for netperf ?
There are some scripts in doc/examples but they are probably a bit long
in the tooth by now.
The main writeup _I_ have on netperf would be the manual, which was
recently updated for
Rick Jones wrote:
If I read the results right it took a 32bit machine from AMD with
a gigabit interface before you could measure a throughput difference.
That isn't shabby for a non-optimized code path.
Just some paranoid ramblings - one needs to look beyond just whether
or not the performance
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 21:34:36 +0200
> So people can choose to immediately flush by setting it to 0. It
> would also be consistent to the flush after route changes, the same
> delay is used there.
That's a good point I hadn't considered.
Therefore, I think
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 22:29:05 +0300 (EEST)
> ...but lets keep in mind that the actual goal is, of course, to get rid of
> the hint altogether, rather than doing these clearing things... :-)
Of course.
The retranmit and forward SKB hints should be easy
* David Miller <[EMAIL PROTECTED]> 2007-03-28 11:24
> Another idea Thomas and I tossed around was to have some kind of way
> for the rule insertion to indicate that the flush should be deferred
> and I kind of prefer that explicitness.
Right, although I believe the flag should not only defer it
bu
On Wed, 28 Mar 2007, David Miller wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Wed, 28 Mar 2007 12:07:09 -0700 (PDT)
>
> > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> > Date: Wed, 28 Mar 2007 16:31:50 +0300 (EEST)
> >
> > > Stupid error from my side. Even though now that I noticed thi
* Kok, Auke <[EMAIL PROTECTED]> wrote:
> Adrian Bunk wrote:
> >Subject: e1000 resume weirdness
> >References : http://lkml.org/lkml/2007/3/26/91
> >Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> >Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]>
> > Auke Kok <[EMAIL PROTECTED]>
>
From: Paul Moore <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 12:36:57 -0400
> Does anyone have access to a public site we could use to host a git
> tree? If no one has anything available (or is willing to maintain
> the tree) I might be able to do something.
It's not difficult to get an account o
From: Joy Latten <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 09:15:15 -0600
> Last night I browsed the ipsec-tools code and saw places in
> racoon where improvement would actually fix this
> problem. I am working on a patch and will pursue this
> on the ipsec-tools mailing list.
>
> I apologize f
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 12:07:09 -0700 (PDT)
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Wed, 28 Mar 2007 16:31:50 +0300 (EEST)
>
> > Stupid error from my side. Even though now that I noticed this,
> > I hoped it would have been an optimization but no
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 16:31:50 +0300 (EEST)
> Stupid error from my side. Even though now that I noticed this,
> I hoped it would have been an optimization but no, the counter
> hint is then incorrect. Thus clearing is necessary for now (I
> still suspect
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 16:24:40 +0300 (EEST)
> It seems I'm being guilty to this one, Dave please apply to net-2.6.22
> (besides this I think the tcp_sync_left_out should be changed but I'll
> prepare a patch for that later). Btw, how should this kind of
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 28 Mar 2007 16:14:17 +0200
> Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
> >
> > Jenkins hash is far from being simple to crack, although with some
> > knowledge it can be done faster.
>
> TCP tends to be initialized early before there is anything
> go
Adrian Bunk wrote:
Subject: e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter : Ingo Molnar <[EMAIL PROTECTED]>
Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]>
Auke Kok <[EMAIL PROTECTED]>
Status : problem is being debugged
The issue comes f
Hi Herbert,
I wonder if you've got a chance to look at netfront in light of the new
stuff in davem's network tree (the stuff that's in
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.22.git).
In particular, struct sk_buff has been changed so that "nh" has gone,
and the replacement can be
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 17:49:03 +0200
> * Jarek Poplawski <[EMAIL PROTECTED]> 2007-03-28 13:19
> > I hope I'm wrong, but isn't this at the cost of admins
> > working with long rules' sets, which (probably) take extra
> > time now?
>
> That's right, it makes t
If I read the results right it took a 32bit machine from AMD with
a gigabit interface before you could measure a throughput difference.
That isn't shabby for a non-optimized code path.
Just some paranoid ramblings - one needs to look beyond just whether or
not the performance of a bulk transfer
Something more
With all kernel debug enabled it was not giving this panic (maybe cause
system becomes too slow).
vanilla kernel 2.6.20.3 with htb patch applied, ethernet cards RTL8139
If u need anythign more - inform me.
Not sure it is iproute2, but if you can, just point me to right directio
On Wed, 28 Mar 2007, Eric Paris wrote:
> It is definitely NOT a shortcut into RHEL.
Ok, that was a poor choice of words on my part.
> I don't want to give the impression that upstream is not coming first.
> All the work is being done upstream either on netdev or linux-audit and
> then I pull it
On Wed, 2007-03-28 at 12:20 -0400, James Morris wrote:
> On Wed, 28 Mar 2007, Joy Latten wrote:
>
> > Eric, sorry as I know you already patched lspp kernel
> > for testing.
>
> I think it'd be better to have the lspp kernel join the upstream workflow
> process, rather than being a shortcut into
On Wed, Mar 28, 2007 at 05:43:22PM +0200, Eric Dumazet wrote:
> Hello David
>
> We could use the nanosec resolution for various functions defined in
> drivers/char/random.c
> (secure_tcpv6_sequence_number(), secure_tcp_sequence_number(),
> secure_dccp_sequence_number())
>
> I am not sure if it'
On Wednesday, March 28 2007 12:20:24 pm James Morris wrote:
> On Wed, 28 Mar 2007, Joy Latten wrote:
> > Eric, sorry as I know you already patched lspp kernel
> > for testing.
>
> I think it'd be better to have the lspp kernel join the upstream workflow
> process, rather than being a shortcut into
On Wed, 28 Mar 2007, Eric Dumazet wrote:
> Hello David
>
> We could use the nanosec resolution for various functions defined in
> drivers/char/random.c
> (secure_tcpv6_sequence_number(), secure_tcp_sequence_number(),
> secure_dccp_sequence_number())
>
> I am not sure if it's a netdev related p
On Wed, 28 Mar 2007, Joy Latten wrote:
> Eric, sorry as I know you already patched lspp kernel
> for testing.
I think it'd be better to have the lspp kernel join the upstream workflow
process, rather than being a shortcut into RHEL.
Please consider creating an lspp git tree (based off Linus' tr
Rusty Russell wrote:
Hi all,
Does something like this make sense for future drivers?
Cheers,
Rusty.
===
Network drivers which keep stats allocate their own stats structure
then write a get_stats() function to return them. It would be nice if
this were done by default.
1) Add a new "st
* Jarek Poplawski <[EMAIL PROTECTED]> 2007-03-28 13:19
> I hope I'm wrong, but isn't this at the cost of admins
> working with long rules' sets, which (probably) take extra
> time now?
That's right, it makes the insert and delete operation more
expensive.
A compromise would be to delay the flushi
Hello David
We could use the nanosec resolution for various functions defined in
drivers/char/random.c
(secure_tcpv6_sequence_number(), secure_tcp_sequence_number(),
secure_dccp_sequence_number())
I am not sure if it's a netdev related patch or core kernel, so I have CC
Andrew.
Thank you
[PA
Last night I browsed the ipsec-tools code and saw places in
racoon where improvement would actually fix this
problem. I am working on a patch and will pursue this
on the ipsec-tools mailing list.
I apologize for any inconvenience.
Eric, sorry as I know you already patched lspp kernel
for testing
On Wed, Mar 28, 2007 at 03:50:47PM +0200, Eric Dumazet wrote:
> 1) We can now use "struct timespec" to get more bits in init_std_data()
That would be a good change, but i don't think it would help that much.
If you know the hardware (e.g. webhost farms tend to have quite
predictive kit) and the ke
SACKED_ACKED and LOST are mutually exclusive, thus this
condition is bug with SACK (IMHO). NewReno, however, could get
enough duplicate ACKs which increment sacked_out, so it makes
sense to do this kind of limitting for non-SACK TCP but not for
SACK-enabled one. Perhaps the author had that in mind
On 28 Mar 2007 16:14:17 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> TCP tends to be initialized early before there is anything
> good in the entropy pool.
>
> static void init_std_data(struct entropy_store *r)
> {
> struct timeval tv;
> unsigned long flags;
>
> spin_lock
Stupid error from my side. Even though now that I noticed this,
I hoped it would have been an optimization but no, the counter
hint is then incorrect. Thus clearing is necessary for now (I
still suspect though that this path is never executed).
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
On Wed, 28 Mar 2007, Patrick McHardy wrote:
> I got this warning with the current net-2.6.22 tree:
>
> KERNEL: assertion ((int)tp->sacked_out >= 0) failed at
> net/ipv4/tcp_input.c (2626)
> Leak s=4294967292 3
>
> Can't say what exactly triggered it.
It seems I'm being guilty to this one, Dave
Andi Kleen <[EMAIL PROTECTED]> writes:
> The only truly variable thing is the
> boot time, which can be guessed
Actually you don't need to guess it. It's in any TCP timestamp.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
>
> Jenkins hash is far from being simple to crack, although with some
> knowledge it can be done faster.
TCP tends to be initialized early before there is anything
good in the entropy pool.
static void init_std_data(struct entropy_store *r)
{
Kirill Korotaev <[EMAIL PROTECTED]> writes:
>> Ideally we can optimize the bridge code or something equivalent to
>> it so that we can take one look at the destination mac address and
>> know which network namespace we should be in. Potentially moving this
>> work to hardware when the hardware s
I got this warning with the current net-2.6.22 tree:
KERNEL: assertion ((int)tp->sacked_out >= 0) failed at
net/ipv4/tcp_input.c (2626)
Leak s=4294967292 3
Can't say what exactly triggered it.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Daniel Lezcano <[EMAIL PROTECTED]> writes:
>>
>>> 3. General observations
>>> ---
>>>
>>> The objective to have no performances degrations, when the network
>>> namespace is off in the kernel, is reached i
On 27-03-2007 14:38, Thomas Graf wrote:
> The results of FIB rules lookups are cached in the routing cache
> except for IPv6 as no such cache exists. So far, it was the
> responsibility of the user to flush the cache after modifying any
> rules. This lead to many false bug reports due to misunderst
On Wed, Mar 28, 2007 at 11:29:43AM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > But I think it can be mostly ignored.
> >
> > With all due respect, it cannot. An attacker with a small-sized botnet
> > (which is ~250 hosts) can create chains that contain well in excess of 3000
> > items
In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 02:26:24 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> > http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/yoshfuji/linux-2.6-fix.git;a=commit;h=33a79bba0cc2f197b46cc54182f94c31ff6ad334
> >
> > I hope this patch will go in 2.6.16-s
>
> > But I think it can be mostly ignored.
>
> With all due respect, it cannot. An attacker with a small-sized botnet
> (which is ~250 hosts) can create chains that contain well in excess of 3000
> items.
Most likely they can also easily generate enough latency data to crack any
simple
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 18:23:34 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 10:48:27 +0200), Agoston
> Horvath <[EMAIL PROTECTED]> says:
>
> > YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > > Would you test with latest kernel, if poss
In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 10:48:27 +0200), Agoston
Horvath <[EMAIL PROTECTED]> says:
> YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > Would you test with latest kernel, if possible, please?
>
> For the archive: switching to 2.6.20.4 fixed this problem.
Thank you for your report.
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 18:16:42 +0900 (JST)
> I hoped we could save some memory per fib6_node,
> but I'm fine with it.
I know, I did not want to add it either :(
Speaking of which, several of the potential fixes for the rt6_probe()
deadlock requ
Hi all,
Does something like this make sense for future drivers?
Cheers,
Rusty.
===
Network drivers which keep stats allocate their own stats structure
then write a get_stats() function to return them. It would be nice if
this were done by default.
1) Add a new "stats" field to "struct n
Hello.
In article <[EMAIL PROTECTED]> (at Sat, 24 Mar 2007 12:44:36 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> The fix for the most serious of them is below, and I'd appreciate
> any feedback if people spot any problems or holes in that approach.
I hoped we could save some memory pe
YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Would you test with latest kernel, if possible, please?
For the archive: switching to 2.6.20.4 fixed this problem.
Thanks!
Agoston
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
On Wed, Mar 28, 2007 at 10:44:31AM +0530, Shani wrote:
> Hi,
>
> Replacing with time_after in drivers/net/eexpress.c
> Applies and compiles clean on latest tree.Not tested.
>
> thanks.
>
> Signed-off-by: Shani Moideen <[EMAIL PROTECTED]>
NAK as not tested. The existing code is known to work so
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 16:57:48 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Wed, 21 Mar 2007 00:26:09 +0100 (CET)),
> YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says:
>
> > In article <[EMAIL PROTECTED]> (at Tue, 20 Mar 2007 15:16:40 -070
On Tue, Mar 27, 2007 at 04:41:54PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> > There is no problem as-is, but I implement unified cache for different
> > sockets (currently tcp/udp/raw and netlink are supported), which does
> > not use that table, so I currently wrap all access code into sp
On Mon, Mar 19, 2007 at 10:49:12AM +0300, Yuriy N. Shkandybin wrote:
> I've changed kernel to rc4 and completely changed hardware.
> Now this is
>
> I've got new trace, but this is another problem as i can see and connected
> with pppoe
>
> ===
80 matches
Mail list logo
