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
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
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
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 a small
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
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
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
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.
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
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
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 being
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 be
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 of
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,
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.
cut
Hi Harry
Can you check which high-res
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 machine
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
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 when
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 other protocols
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
previously.
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.
cut
Hi Harry
Can
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
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
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(struct
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
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
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 1G
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 of
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 was
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 flag
[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]
[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: [EMAIL
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
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
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.
[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
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 this. I can
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
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
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 knowledge
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 via
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
---
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
43 matches
Mail list logo
