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 2.
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
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 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
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 me
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 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
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
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 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 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.
Hi Harry
Can you check which "high-res timesourc
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
> 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 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
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
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
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
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
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
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
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
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 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 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
[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: [EMA
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
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
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
[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
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 m
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
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
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
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
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.
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
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
47 matches
Mail list logo
