From: Shuya MAEDA <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2006 14:36:46 +0900
> #define PSCHED_TADD2(tv, delta, tv_res) \
> ({ \
> - int __delta = (tv).tv_usec + (delta); \
> - (tv_res).tv_sec = (tv).tv_sec; \
> - if (__delta > USEC_PER_SEC) { (tv_res).tv_sec++; __delta
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2006 09:30:35 +0400
> Attached patch declares connector init function as subsys_init()
> and returns -EAGAIN in case connector is not initialized yet.
>
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Applied, but I had to fixup
Someone put a wired usb-to-ethernet adapter into a system running
the 2.6.13.5 kernel. The driver is evidently the rtl8150, and this
person sent me what appeared to be a modified version of the rtl8150
that is in the kernel. The kernel driver does not appear to even attempt
to use this device.
On Wed, Jun 14, 2006 at 11:40:04AM +0200, Jesper Dangaard Brouer wrote:
> The Linux traffic's control engine inaccurately calculates
> transmission times for packets sent over ADSL links. For some
> packet sizes the error rises to over 50%. This occurs because ADSL
> uses ATM as its link layer t
We should preallocate IV+ICV space when encrypting the frame.
Currently no problem shows up just because dev_alloc_skb aligns the
data len to SMP_CACHE_BYTES which can be used for ICV.
Thanks,
Hong
diff -urp a/net/ieee80211/ieee80211_tx.c b/net/ieee80211/ieee80211_tx.c
--- a/net/ieee80211/ieee8021
Harry Edmon <[EMAIL PROTECTED]> wrote:
>
> That did not help. I have 1 minute outputs from tcpdump under both 2.6.11.12
> and 2.6.16.20. You will see a large size difference between the files.
> Since
> the 2.6.11.12 one is 2 MBytes, I thought I would post them via the web
> instead
> of v
jamal wrote:
> You are still speaking ATM (and the above may still be valid), but:
> Could you for example look at the netdevice->type and from that figure
> out the link layer overhead and compensate for it.
> Obviously a lot more useful if such activity is doable in user space
> without any know
jamal wrote:
> - For further reflection: Have you considered the case where the rate
> table has already been considered on some link speed in user space and
> then somewhere post-config the physical link speed changes? This would
> happen in the case where ethernet AN is involved and the partner m
On Mon, Jun 19, 2006 at 03:20:10PM -0700, Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=6682
> >
> >Summary: BUG: soft lockup detected on CPU#0! / ksoftirqd takse
> > 100% CPU
> > Kernel Version: 2.6.15.6
> >
On Mon, 2006-06-19 at 22:43 +0200, Michael Buesch wrote:
> On Monday 19 June 2006 17:23, Daniel Gryniewicz wrote:
> > On Sat, 2006-06-17 at 19:28 +0200, Michael Buesch wrote:
> > > Hi,
> > >
> > > This patch adds full 32-bit and 64-bit DMA support
> > > to the bcm43xx driver. Well, it _should_ do
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6698
>
>Summary: unregister_netdevice hangs indefinitely from
> /proc/sys/net/ipv6/conf/all/forwarding
> Kernel Version: 2.6.17-rc6
> Status: NEW
> Severity: normal
>
jamal wrote:
> Folks,
>
> Attached is a document that should help people wishing to use generic
> netlink interface. It is a WIP so a lot more to go if i see interest.
> The doc has been around for a while, i spent part of yesterday and this
> morning cleaning it up. If you have sent me comments b
On Mon, Jun 19, 2006 at 10:36:50AM -0400, jamal wrote:
>
> Ok, but:
> The queue lock will ensure only one of the qdisc runs (assuming
> different CPUs) will be able to dequeue at any one iota in time, no?
> And if you assume that the cpu that manages to get the tx lock as well
> is going to be con
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6682
>
>Summary: BUG: soft lockup detected on CPU#0! / ksoftirqd takse
> 100% CPU
> Kernel Version: 2.6.15.6
> Status: NEW
> Severity: normal
> Owner: [EMA
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6681
>
>Summary: TC crash and rule freeze
> Kernel Version: 2.6.16-gentoo-r6
> Status: NEW
> Severity: normal
> Owner: [EMAIL PROTECTED]
> Submitter: [EMAIL PROTECTED
Hi John,
Please apply this to wireless-dev.
There is no real reason to delay it, even _if_ there might
be still bugs in it. It's a development tree. That's what it is for. ;)
--
Get AccessPoint mode working in bcm43xx-d80211.
This patch is derived from Alexander Tsvyashchenko's original
patch. I
On Monday 19 June 2006 19:34, Chris Friesen wrote:
> Andi Kleen wrote:
> > Incoming packets are only time stamped
> > when someone asks for the timestamps.
>
> Doesn't that add scheduling latency to the timestamps? Or is is a flag
> that gets set to trigger timestamping at packet arrival?
It's a
On Mon, Jun 19, 2006 at 03:41:40PM -0500, Jon Mason wrote:
> I believe it is preferred to be a compile option for non-gigabit
> drivers, given that it will be eating a lot of cycles for infrequent
> packets (especially for the 10Mb). I believe there was a thread about
> this last year when e100 wa
On Monday 19 June 2006 17:23, Daniel Gryniewicz wrote:
> On Sat, 2006-06-17 at 19:28 +0200, Michael Buesch wrote:
> > Hi,
> >
> > This patch adds full 32-bit and 64-bit DMA support
> > to the bcm43xx driver. Well, it _should_ do this. I can
> > not test it, as I don't have a machine to trigger the
On Fri, Jun 16, 2006 at 12:11:54PM -0700, Don Fry wrote:
> This patch is a collection of changes to pcnet32 which does the
> following:
>
> - Fix section mismatch warning.
> - fix set_ringparam to correctly handle memory allocation failures
> - fix off-by-one in get_ringparam.
> - cleanup at end
On Thu, 15 Jun 2006, jamal wrote:
On Thu, 2006-15-06 at 10:47 +1000, Russell Stuart wrote:
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
The other problem I see with this code is it is very tightly tied to ATM
cell sizes, not to solving the generic question of packetisation.
Others ha
This patch implements wrapper functions that provide a convenient way to
access the sockets API for in-kernel users like sunrpc, cifs & ocsf2 etc
and any future users.
The only change from the version i submitted last week is the renaming of
kernel_ioctl to kernel_sock_ioctl.
I left the e
This patch updates sunrpc to use in-kernel sockets API.
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -388,7 +388,7 @@ svc_sendto(str
On Mon, 19 Jun 2006, Andi Kleen wrote:
If you use "pmtmr" try to reboot with kernel option "clock=tsc".
That's dangerous advice - when the system choses not to use
TSC it often has a reason.
Sorry, it was not a general advice, just something to try out. It really
solved my network perform
Andi Kleen wrote:
Incoming packets are only time stamped
when someone asks for the timestamps.
Doesn't that add scheduling latency to the timestamps? Or is is a flag
that gets set to trigger timestamping at packet arrival?
Chris
-
To unsubscribe from this list: send the line "unsubscribe n
James Morris <[EMAIL PROTECTED]> wrote on 06/18/2006 04:04:06 AM:
> On Sun, 18 Jun 2006, Catherine Zhang wrote:
>
> I'd also mention here that this is to complement the SO_PEERSEC option
for
> stream sockets.
>
OK.
> There's an implementation issue, which I'm sure has been mentioned
> prev
Jesper Dangaard Brouer wrote:
Harry Edmon <[EMAIL PROTECTED]> wrote:
I have a system with a strange network performance degradation from
2.6.11.12 to most recent kernels including 2.6.16.20 and
2.6.17-rc6. The system is has Dual single core Xeons with
hyperthreading on.
Hi Harry
Can y
On Mon, 19 Jun 2006, jamal wrote:
> Other that TIPC the two other users i have seen use it in this manner.
> But, you are right if usage tends to lean in some other way we could get
> rid of it (I think TIPC is a bad example).
Ok, perhaps make a note in the docs about this and keep an eye out whe
jamal wrote:
> On Mon, 2006-19-06 at 11:13 -0400, James Morris wrote:
>
>
>>It seems that TIPC is multiplexing all of it's commands through
>>TIPC_GENL_CMD.
>
>
>
> TIPC is a deviation; they had the 100 ioctls and therefore did a direct
> one-to-one mapping.
>
>
>>I wonder, if this is how
On Mon, 2006-19-06 at 11:13 -0400, James Morris wrote:
>
> It seems that TIPC is multiplexing all of it's commands through
> TIPC_GENL_CMD.
TIPC is a deviation; they had the 100 ioctls and therefore did a direct
one-to-one mapping.
> I wonder, if this is how other protocols are likely to uti
> If you use "pmtmr" try to reboot with kernel option "clock=tsc".
That's dangerous advice - when the system choses not to use
TSC it often has a reason.
>
> On my Opteron AMD system i normally can route 400 kpps, but with
> timesource "pmtmr" i could only route around 83 kpps. (I found the t
On Sat, 2006-06-17 at 19:28 +0200, Michael Buesch wrote:
> Hi,
>
> This patch adds full 32-bit and 64-bit DMA support
> to the bcm43xx driver. Well, it _should_ do this. I can
> not test it, as I don't have a machine to trigger the 1G
> limit.
> The 1G limit should be exploitable on an AMD64 machi
On Mon, 19 Jun 2006, jamal wrote:
> Attached is a document that should help people wishing to use generic
> netlink interface. It is a WIP so a lot more to go if i see interest.
Thanks for writing this up.
It seems that TIPC is multiplexing all of it's commands through
TIPC_GENL_CMD.
I wonder
On Fri, Jun 16, 2006 at 12:11:54PM -0700, Don Fry wrote:
> This patch is a collection of changes to pcnet32 which does the
> following:
>
> - Fix section mismatch warning.
> - fix set_ringparam to correctly handle memory allocation failures
> - fix off-by-one in get_ringparam.
> - cleanup at end
Harry Edmon <[EMAIL PROTECTED]> wrote:
I have a system with a strange network performance degradation from
2.6.11.12 to most recent kernels including 2.6.16.20 and 2.6.17-rc6.
The system is has Dual single core Xeons with hyperthreading on.
Hi Harry
Can you check which "high-res timesourc
On Tue, 2006-20-06 at 00:29 +1000, Herbert Xu wrote:
> Correct. When qdisc_run happens we take an skb off the head of the
> queue. If it can't be transmitted right away, we try to put it back
> in the same spot.
>
> If you have two qdisc_run's happening at the same time then that spot
> could b
On Mon, Jun 19, 2006 at 10:23:29AM -0400, jamal wrote:
>
> Ok, I am trying to visualize but having a hard time:
> Re-queueing is done at the front of the queue to maintain ordering
> whereas queueing is done at the front (i.e it is a FIFO). i,e
> even if p2 comes in and gets queued while p1 is bei
Herbert,
On Mon, 2006-19-06 at 23:42 +1000, Herbert Xu wrote:
> Hi Jamal:
>
> On Mon, Jun 19, 2006 at 09:33:51AM -0400, jamal wrote:
[..]
>
> Actually I discovered the problem only because the generic segmentation
> offload stuff that I'm working on needs to deal with the situation where
> a sup
Stephen Hemminger wrote:
Does this fix it?
# sysctl -w net.ipv4.tcp_abc=0
That did not help. I have 1 minute outputs from tcpdump under both 2.6.11.12
and 2.6.16.20. You will see a large size difference between the files. Since
the 2.6.11.12 one is 2 MBytes, I thought I would post them
Hi Jamal:
On Mon, Jun 19, 2006 at 09:33:51AM -0400, jamal wrote:
>
> I take it you saw a lot of requeues happening that prompted this? What
> were the circumstances? The _only_ times i have seen it happen is when
> the (PCI) bus couldnt handle the incoming rate or there was a bug in the
> driver.
Folks,
Attached is a document that should help people wishing to use generic
netlink interface. It is a WIP so a lot more to go if i see interest.
The doc has been around for a while, i spent part of yesterday and this
morning cleaning it up. If you have sent me comments before, please
forgive me
Herbert,
I take it you saw a lot of requeues happening that prompted this? What
were the circumstances? The _only_ times i have seen it happen is when
the (PCI) bus couldnt handle the incoming rate or there was a bug in the
driver.
Also: what happens to the packet that comes in from either local
Hi Dave:
I'm nearly done with the generic segmentation offload stuff (although
only TCPv4 is implemented for now), and I encountered this problem.
[NET]: Prevent multiple qdisc runs
Having two or more qdisc_run's contend against each other is bad because
it can induce packet reordering if the pa
On Monday 19 June 2006 11:37, Francois Barre wrote:
> 2006/6/18, Michael Buesch <[EMAIL PROTECTED]>:
> > Ok, I got my Airport to generate Beacons on this BE machine.
>
> Hurray, I'm not alone running BE stuff here...
>
> > There was a bug hiding in bcm43xx_ram_write().
> [..]
> Could you provide
Hi,
This patch enables the usage of a bcm43xx card as AP with
the Devicescape 802.11 stack.
Well, it does not work 100%, but at least it's very promising.
We are able to create a bssid and correctly send beacon frames out.
This patch is tested on BE and LE machines.
There seem to be issues with
Mark Lord wrote:
Unilaterally following the standard is all well and good
for those who know how to get around it when a site becomes
inaccessible, but not for Joe User.
So lets enable it in the kernel, and let the distros turn it off.
The Joe User who isn't a kernel hacker won't be running 2.
I found two problems in PSCHED_TADD() and PSCHED_TADD2().
1) These function increment tv_sec if tv_usec > 100.
But I think it should "if tv_usec >= 100".
2) tv_usec became 120 or more when I used CBQ and
experimented it. It is not correct to exceed 100
because tv_usec is
47 matches
Mail list logo
