I haven't had time to go back and find where is started (my prior kernel
was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a
problem where when transfering large amounts of data (trying to ftp a TB
or so of data off of the box to my new server it will run for a while (as
little
On Fri, May 12, 2006 at 01:53:44AM +0200, Brice Goglin ([EMAIL PROTECTED])
wrote:
Imho you will want to work directly with pages shortly.
We had thought about doing this, but were a little nervous since we did
not know of any other drivers that worked directly with pages. If this
is
Hello.
I have setup NETEM between to devices that are sending eachother RTP voice
packets.
VOICE1_RTP (eth1)NETEM_LINUX_BOX (eth2) VOICE2_RTP
I am attempting to introduce delay via netem. tc qdisc add dev eth1 root netem
delay 100ms
This appears to work for ICMP (ping) traffic or
On Thu, May 11, 2006 at 11:54:09AM -0700, David S. Miller ([EMAIL PROTECTED])
wrote:
BTW you make another massively critical error in your analysis of TCP
profiles.
You mention that tcp_v4_rcv() shows up in your profiles and not
__inet_lookup(). This __inet_lookup() is inlined, and thus
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
---
drivers/net/tg3.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
5ed8e79c778ee803e44a325a1e15c0cb3f52d0ff
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index beeb612..0b5bc93
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote:
Ok, I've let the release time between -rc's slide a bit too much again,
but -rc4 is out there, and this is the time to hunker down for 2.6.17.
If you know of any regressions, please holler now, so that we don't miss
them.
I
On Friday 12 May 2006 12:24, you wrote:
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote:
Ok, I've let the release time between -rc's slide a bit too much again,
but -rc4 is out there, and this is the time to hunker down for 2.6.17.
If you know of any regressions, please
On Wed, 10 May 2006 13:31:39 -0400, Michael Wu wrote:
I think this is overkill to fix a hack. IMHO, scan_skip_11b shouldn't exist
in
the first place. One alternative would be to modify 802.11g drivers to not
set IEEE80211_CHAN_W_SCAN on 802.11b channels when there are equivalent
802.11g
This subthread in the Xen patch thread has now digressed onto discussions
about entropy and security. Perhaps you guys could add some points.
Well, I can try. I don't think this answers any questions, but
perhaps it informs the discussion. Apologies if the Cc: list is
getting a bit bloated.
On Fri, May 12, Michael Buesch wrote:
On Friday 12 May 2006 12:24, you wrote:
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote:
Ok, I've let the release time between -rc's slide a bit too much again,
but -rc4 is out there, and this is the time to hunker down for 2.6.17.
On Fri, May 12, 2006 at 12:44:22PM +0200, Michael Buesch wrote:
On Friday 12 May 2006 12:24, you wrote:
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote:
Ok, I've let the release time between -rc's slide a bit too much again,
but -rc4 is out there, and this is the time to
This time I checked more carefully my changeset and split it into
smaller parts. Few of my patches was tested by OpenZaurus users, some
are waiting for testing.
We switched to pcmciautils when moved to 2.6.16 and many users complain
that their WiFi CompactFlash cards are driven by orinoco
Not sure about removing this card from orinoco driver and should I add
PCMCIA_DEVICE_MANF_CARD or does PCMCIA_DEVICE_PROD_ID* is enough.
---
Here's another card that would benefit from a hostap driver:
Platform: Sharp Zaurus
I use D-Link DCF-660W card with WPA protected network. By default
orinoco_cs was loaded for my card so I was not able to connect. This patch
make my card working with hostap_cs (like it was when I used pcmcia-cs).
Card was used with hostap_cs during last year in two Zaurus models (2.4.18
on one
One more Prism2 card which works with HostAP.
Platform: Sharp Zaurus SL-5500 running 2.4.18 + hostap_cs 0.4.7
[EMAIL PROTECTED]:~# cardctl ident
Socket 0:
product info: NETGEAR, MA701 Wireless CF Card,
manfid: 0xd601, 0x0002
function: 6 (network)
[EMAIL PROTECTED]:~# ifconfig wlan0
wlan0
Platform: Sharp Zaurus SL-C3100 running 2.6.16 + pcmciautils 013
[EMAIL PROTECTED]:~# pccardctl ident
Socket 0:
product info: HITACHI, microdrive, ,
manfid: 0x0319, 0x
function: 4 (fixed disk)
Socket 1:
product info:PLANEX COMMUNICATION INC,PLANEX GW-CF11X Wireless CF Card,
,
On Fri, 12 May 2006 11:36:24 +1000
David Arnold [EMAIL PROTECTED] wrote:
i've been getting semi-regular lockups on my machine over 2.6.16
series. I recently attached a serial console in an attempt to capture
an OOPS.
i got one yesterday. it's copied manually from the console, but
On Fri, 2006-05-12 at 12:05 +0200, Karsten Keil wrote:
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
ACK. Thanks. Please add sign-off line and send to DaveM.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
Marcin Juszkiewicz wrote :
This time I checked more carefully my changeset and split it into
smaller parts. Few of my patches was tested by OpenZaurus users, some
are waiting for testing.
I'm sorry, but I will have again to veto part of your patch.
You are removing IDs from
Dnia piątek, 12 maja 2006 15:40, Marcin Juszkiewicz napisał:
Not sure about removing this card from orinoco driver and should I add
PCMCIA_DEVICE_MANF_CARD or does PCMCIA_DEVICE_PROD_ID* is enough.
Updated to not touch orinoco_cs driver.
Dnia piątek, 12 maja 2006 18:57, Jean Tourrilhes napisał:
Marcin Juszkiewicz wrote :
I'm sorry, but I will have again to veto part of your patch.
You are removing IDs from the Orinoco driver. Please don't do
that, those card work perfectly with the orinoco driver, and some of
us
Updated to not touch orinoco_cs driver.
---
I use D-Link DCF-660W card with WPA protected network. By default
orinoco_cs was loaded for my card so I was not able to connect. This patch
make my card working with hostap_cs (like
On Fri, May 12, 2006 at 07:59:54AM -0700, Michael Chan wrote:
ACK. Thanks. Please add sign-off line and send to DaveM.
This time with Signed-off line.
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
Signed-off-by: Karsten Keil [EMAIL PROTECTED]
---
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 12 May 2006 10:47:11 +0400
On Fri, May 12, 2006 at 01:53:44AM +0200, Brice Goglin ([EMAIL PROTECTED])
wrote:
Imho you will want to work directly with pages shortly.
We had thought about doing this, but were a little nervous
From: Karsten Keil [EMAIL PROTECTED]
Date: Fri, 12 May 2006 19:46:23 +0200
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
Signed-off-by: Karsten Keil [EMAIL PROTECTED]
Applied, thanks a lot Karsten.
-
To unsubscribe from this list: send the line
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 11 May 2006 11:28:43 -0700
Many users of skb_checksum_help() are just using it to recalculate
outbound checksum, so why not expose the interface in a more useful
way. Suggested by Ingo Oeser.
Signed-off-by: Stephen Hemminger [EMAIL
On Sun, 7 May 2006 12:18:59 +0200 Stefan Rompf wrote:
Hi,
seems documentation got lost when the RFC2863-patch was applied. Having
documentation is good, so I resend it ;-)
I have a few comments/questions about this.
--- /dev/null 2005-03-19 20:36:14.0 +0100
+++
Hi,
I just saw this last night when my desktop was shutting down. Not all
the OOPS was outputted, but I've found where it happens.
in forcedeth.c:1583 we see:
pci_unmap_single(np-pci_dev, np-rx_dma[i],
np-rx_skbuff[i]-end-np-rx_skbuff[i]-data,
On Fri, 2006-05-12 at 09:57 -0700, Jean Tourrilhes wrote:
Marcin Juszkiewicz wrote :
This time I checked more carefully my changeset and split it into
smaller parts. Few of my patches was tested by OpenZaurus users, some
are waiting for testing.
I'm sorry, but I will have again
convert au1000_eth driver to use PHY framework
Signed-off-by: Herbert Valerio Riedel [EMAIL PROTECTED]
---
drivers/net/Kconfig |1
drivers/net/au1000_eth.c | 1602 +++---
drivers/net/au1000_eth.h | 134
3 files changed, 380 insertions(+),
On Friday 12 May 2006 06:47, you wrote:
It seems like hw_modes is more useful for saying
what modes shouldn't be used than saying what modes are supported by the
hardware and should be used.
This is exactly the purpose of hw_modes. This also means you don't need
any validation.
Hm, so
Hello!
As a co-maintainer of Orinoco driver, I'd like to ask the netdev team
not to apply any patch from Marcin Juszkiewicz touching the Orinoco
driver without my or David's explicit approval.
I'm fine with patches that change e.g. all PCMCIA or PCI drivers across
the board, but not with patches
On Fri, 2006-05-12 at 15:21 +0200, Marcin Juszkiewicz wrote:
All patches require 24_hostap_cs_id.diff from Pavel Roskin.
This patch was never submitted. Please ignore the series.
--
Regards,
Pavel Roskin
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
On Friday 12 May 2006 13:23, you wrote:
I got assertion failures in the bcm43xx driver:
bcm43xx: Chip ID 0x4318, rev 0x2
That is expected an non-fatal.
Is this one in the same category?
[ 79.087115] bcm43xx: WARNING: Writing invalid LOpair (low: 46, high: 104,
index: 123)
On Friday 12 May 2006 13:47, you wrote:
On Fri, May 12, 2006 at 12:44:22PM +0200, Michael Buesch wrote:
On Friday 12 May 2006 12:24, you wrote:
On Thu, May 11, 2006 at 04:44:03PM -0700, Linus Torvalds wrote:
Ok, I've let the release time between -rc's slide a bit too much again,
but
I'm running a slightly modified 2.6.16.13 kernel on FC5-amd64. The motherboard
is SuperMicro H8SSL dual-core AMD system. According to super-micro web site,
the PCI-X slot is 133Mhz. I'm using a 4-port pro/1000 NIC.
dmesg shows a listing of 120Mhz:
Intel(R) PRO/1000 Network Driver - version
Ben Greear wrote:
I'm running a slightly modified 2.6.16.13 kernel on FC5-amd64. The
motherboard
is SuperMicro H8SSL dual-core AMD system. According to super-micro web
site,
the PCI-X slot is 133Mhz. I'm using a 4-port pro/1000 NIC.
dmesg shows a listing of 120Mhz:
Intel(R) PRO/1000
ports:
http://devzero.co.uk/~alistair/oops-20060512/
It was initially difficult to reproduce, but I found I could do so reliably if
I ssh'ed into the box and halted it remotely, then it would always oops on
shutdown. I assume this is because the driver is still active when something
happens
On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote:
I haven't had time to go back and find where is started (my prior kernel
was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a
problem where when transfering large amounts of data (trying to ftp a TB
where is started sounds
Ben Greear wrote:
I'm running a slightly modified 2.6.16.13 kernel on FC5-amd64. The
motherboard
is SuperMicro H8SSL dual-core AMD system. According to super-micro web
site,
the PCI-X slot is 133Mhz. I'm using a 4-port pro/1000 NIC.
dmesg shows a listing of 120Mhz:
IIRC there is a bridge
Auke Kok wrote:
obviously 120 is missing, but PCI-E speeds are also missing (2500gbps). The
output of the e1000 module is correct.
Any idea why 120Mhz is used instead of 133? It doesn't
seem to matter in my performance tests, but I am curious...
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
On Fri, 12 May 2006, Roger Luethi wrote:
On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote:
I haven't had time to go back and find where is started (my prior kernel
was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a
problem where when transfering large amounts of data
Andrew Morton writes:
xeb (who forgot to do reply-to-all) tells me that pptpd uses ptys.
I tried to replicate this using pppd running on a pty, with a
charshunt process on the master side of the pty transferring
characters between it and a socket. I didn't see any freezeups in
either
43 matches
Mail list logo
