On Tue, 19 Sep 2006 16:45:06 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> looks OK except for the tasklet, which may starve if the lock is being
> held upon entry
>
>
Why would the tasklet starve anymore than NAPI?
Worst case, the transmitters fill the ring completely and have to
wait for th
Jeff Garzik wrote:
FYI, note that I killed some OS wrappers from osdep.h in e1000 and ixgb
excellent, I am ashamed I didn't get to that myself yet :)
Thanks!
Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
This patch already is in 2.6.17 stable, but the bigger version was pushed
off till 2.6.19. Here is a less intrusive version that needs to go into 2.6.18
(or I'll end up sending it for 2.6.18.1). The driver was telling the
GMAC to flush (not process) pause frames. Manually disabling pause wasn't
wor
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 19 Sep 2006 13:41:32 -0700
> Bert's attempt was noble
> It showed your desire for the truth
> A simple path existed
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, but...
net/ipv4/Kconfig:607:warning: defaults for choice v
New tcp default config
means we can eliminate the hack
that was used previous
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- net-2.6.19.orig/net/ipv4/Kconfig2006-09-19 14:27:58.0 -0700
+++ net-2.6.19/net/ipv4/Kconfig 2006-09-19 14:28:17.0 -0700
@@ -602,10 +602,6 @@
On Tue, Sep 19, 2006 at 10:28:38AM -0700, Kok, Auke wrote:
>
> Refine cb cleaning debug printout and print out all cleaned cbs' status. Add
> debug flag for EEPROM csum failures that were overridden by the user.
>
> Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
> Signed-off-by: Auke K
On Tue, Sep 19, 2006 at 02:20:07PM -0700, David Miller wrote:
> > Bert's attempt was noble
> > It showed your desire for the truth
It was also crap :-)
> Applied, but...
> net/ipv4/Kconfig:607:warning: defaults for choice values not supported
It does appear to do the right thing in all cases I
Dave Jones wrote:
On Tue, Sep 19, 2006 at 10:28:38AM -0700, Kok, Auke wrote:
>
> Refine cb cleaning debug printout and print out all cleaned cbs' status. Add
> debug flag for EEPROM csum failures that were overridden by the user.
>
> Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
>
Jeff Garzik wrote:
Kok, Auke wrote:
Unify our shutdown/suspend/resume code and make it similar to e1000:
e1000_shutdown now calls suspend which does the exact same thing on
shutdown except saving PCI config state on suspend. WoL setup code
is now also more simple and works even when CONFIG_PM is
On Tue, Sep 19, 2006 at 02:32:09PM -0700, Stephen Hemminger wrote:
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
# CONFIG_TCP_CONG_ADVANCED is not set
# CONFIG_DEFAULT_BIC is not set
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CON
On Tue, Sep 19, 2006 at 05:40:34PM -0400, Jeff Garzik wrote:
> Dave Jones wrote:
> > On Tue, Sep 19, 2006 at 10:28:38AM -0700, Kok, Auke wrote:
> > > + add_taint(TAINT_MACHINE_CHECK);
> >
> > I object to this flag being abused this way.
> > A corrupt EEPROM on a networ
Jeff Garzik wrote:
Kok, Auke wrote:
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -90,15 +90,6 @@ typedef enum {
e1000_100_full = 3
} e1000_speed_duplex_type;
-/* Flow Control Settings */
-typedef enum {
-e1000_fc_none = 0,
-e1000_fc_rx_pause = 1,
-
Hi Dave,
According to NatSemi datasheet, the configuration base address for the PC8738x
family is 0x2e or 0x164. 0x0 doesn't appear in any datasheet.
Patch from Lamarque Vieira Souza <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/nsc-ircc.c |2 +-
1
FIFOCTL_RXERR and FIFOCTL_TXERR are undocumented bits, according to the
Sigmatel datasheet. We should thus not take any assumption on their values
and semantics.
Problem spotted by andrzej zaborowski <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/stir420
This patch detects the smsc-ircc chipset on the nx1000
(including nx7000 and nx7010) and the nx5000 HP/Compaq laptop series.
Patch from "Linus Walleij (LD/EAB)" <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/smsc-ircc2.c | 38 +
Dave Jones wrote:
On Tue, Sep 19, 2006 at 05:40:34PM -0400, Jeff Garzik wrote:
> Dave Jones wrote:
> > On Tue, Sep 19, 2006 at 10:28:38AM -0700, Kok, Auke wrote:
> > > + add_taint(TAINT_MACHINE_CHECK);
> >
> > I object to this flag being abused this way.
> > A corrup
Jeff Garzik wrote:
Kok, Auke wrote:
Refine cb cleaning debug printout and print out all cleaned cbs'
status. Add
debug flag for EEPROM csum failures that were overridden by the user.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
ACK patch, NA
From: bert hubert <[EMAIL PROTECTED]>
Date: Tue, 19 Sep 2006 23:43:05 +0200
> On Tue, Sep 19, 2006 at 02:32:09PM -0700, Stephen Hemminger wrote:
> > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
>
> # CONFIG_TCP_CONG_ADVANCED is not set
> # CONFIG_DEFAULT_BIC is not set
> # CONFIG_DEFAULT_
Not that I've been able to uncover.
Thanks for fixing this..
- Original Message -
From: "Stephen Hemminger" <[EMAIL PROTECTED]>
To: "Andrew Hall" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, September 20, 2006 6:31 AM
Subject: Re: [PATCH 1/3] sky2: tx pause bug fix
On Mon, 11 Sep 2006
> When TCP_CONG_ADVANCED is disabled, TCP_CONG_BIC should always be set
> and be the default, but that's not what the new code is doing.
>
> I'm reverting Stephen's patch (again) until this is all sorted
> out as things are still broken in various ways even with the
> followon patch.
I don't see
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 19 Sep 2006 16:02:02 -0700
>
> > When TCP_CONG_ADVANCED is disabled, TCP_CONG_BIC should always be set
> > and be the default, but that's not what the new code is doing.
> >
> > I'm reverting Stephen's patch (again) until this is all sorted
> However, I presume someone added the __powerpc__ define here
> because they picked up a 3c509 at a garage sale, stuck it in
> a powerpc, found out it didn't work due to a byte-swapping bug,
> and then patched it as above. I'm disturbed that somehow
> outsl_ns() became identical to outsl() at
On Tue, 19 Sep 2006 16:04:41 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Tue, 19 Sep 2006 16:02:02 -0700
>
> >
> > > When TCP_CONG_ADVANCED is disabled, TCP_CONG_BIC should always be set
> > > and be the default, but that's not what t
On Tue, 2006-09-19 at 20:52 +0200, Matt Sealey wrote:
> Some northbridges and PCI bridges have "clever" byteswapping in
> hardware, maybe this is just an effect of that. In theory depending on
> the host bridge, you should pass in big endian data and have it swap or
> not swap, not pick that way
Stephen Hemminger wrote:
On Tue, 19 Sep 2006 16:45:06 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
looks OK except for the tasklet, which may starve if the lock is being
held upon entry
Why would the tasklet starve anymore than NAPI?
Worst case, the transmitters fill the ring completely an
Linas Vepstas writes:
> The rest of this patch might indeed be correct, but the above comment
> bothers me. The "ns" versions of routines are supposed to be
> non-byte-swapped versions of the insl/outsl routines (which would
> byte-swap on big-endian archs such as powerpc.)
If it were true that
On Tue, 19 Sep 2006 16:26:12 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Tue, 19 Sep 2006 16:45:06 -0400
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> looks OK except for the tasklet, which may starve if the lock is being
> >> held upon entry
> >>
> >>
> >
Nah. We have the basic rule that readl/writel are little endian.
PowerPC
additionally provides arch specific low level in_{be,le}32 type
accessors with explicit endianness. Or you can also use
cpu_to_le32/le32_to_cpu kind of macros to convert between native and
explicit endianness.
Sure, PCI b
On Wed, 2006-09-20 at 02:21 +0200, Segher Boessenkool wrote:
> > Nah. We have the basic rule that readl/writel are little endian.
> > PowerPC
> > additionally provides arch specific low level in_{be,le}32 type
> > accessors with explicit endianness. Or you can also use
> > cpu_to_le32/le32_to_cpu
Segher Boessenkool wrote:
Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
only?
Yes.
For other buses, use foo_writel(), etc.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
only? I sure hope not.
It's defined for PCI and possibly ISA memory. You can use it for other
things if you whish to, but "other things" are arch specific in any
case.
Huh? You're saying that only PCI and ISA are standardis
Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
only?
Yes.
For other buses, use foo_writel(), etc.
Can this please be documented then? Never heard this before...
Segher
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EM
From: Chuck Short <[EMAIL PROTECTED]>
Fix memory leak.
Coverity id# 653
patch location:
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=a1f34cb68b16807ed9d5ebb0f6a6ec5ff8a5fc78
Signed-off-by: Chuck Short <[EMAIL PROTECTED]>
Signed-off-by: Ben Collins <[EM
From: Jesper Juhl <[EMAIL PROTECTED]>
I recently tried running netconsole via a vlan interface without luck,
and decided to do something about it (see patch below).
My interfaces look like this:
eth0 Link encap:Ethernet HWaddr 00:14:5E:28:3C:2E
UP BROADCAST RUNNING MULTICAST MTU
From: Pavel Machek <[EMAIL PROTECTED]>
This cleans up bluetooth a bit, no code changes.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Cc: Marcel Holtmann <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/bluetooth/hci_ldisc.c | 13 +
1 file changed
From: Fabio Olive Leite <[EMAIL PROTECTED]>
A while ago Ingo patched tcp_v4_rcv on net/ipv4/tcp_ipv4.c to use
bh_lock_sock_nested and silence a lock validator warning. This fixed
it for IPv4, but recently I saw a report of the same warning on IPv6.
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: "David S.
From: Randy Dunlap <[EMAIL PROTECTED]>
WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text: from
.text between 'he_start' (at offset 0x218a) and 'he_service_tbrq'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/atm/
Hi,
I am alarmed and embarassed that sloppy comments on my part has turned
onto a long conversation.
On Wed, Sep 20, 2006 at 02:58:39AM +0200, Segher Boessenkool wrote:
> >> Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
> >> only? I sure hope not.
> >
> > It's defined for
Segher Boessenkool wrote:
Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
only?
Yes.
For other buses, use foo_writel(), etc.
Can this please be documented then? Never heard this before...
You have come late to the party. This has been the case for many, many
years.
Well, I'm having trouble thinking of other busses that have as strong
a sense of the "address-data" style I/O as PCI. Busses like scsi and
ide are primarily "command-data" or "data-data" in style. Only the
address-data style busses need readl/writel-style routines.
SBUS, JBUS, VMEbus, NuBus, Ra
In article <[EMAIL PROTECTED]> (at Tue, 19 Sep 2006 18:26:29 +0200), Nicolas
DICHTEL <[EMAIL PROTECTED]> says:
> > + if (pneigh)
> > + is_router = pneigh->flags & NTF_ROUTER;
> >
> In function ndisc_send_na(), is_router must be 1 or 0, doesn't it ? Because,
> icmph.icmp6_router is
[ Charset ISO-8859-1 unsupported, converting... ]
> Amy Fong wrote:
> > [PATCH] Add Broadcom PHY support
> >
> > This patch adds a driver to support the bcm5421s and bcm5461s PHY
> >
> > Kernel version: linux-2.6.18-rc6
> >
> > Signed-off-by: Amy Fong <[EMAIL PROTECTED]>
>
> And... where are t
On Tue, 19 Sep 2006, Amy Fong wrote:
> > And... where are the users of this phy driver?
[...]
> This phy driver is used by the WRS's sbc8560 (bcm5421s) and sbc843x
> (bcm5461s) via the gianfar driver.
And sb1250-mac.c would be happy to use it too.
Maciej
-
To unsubscribe from this list: send
Maciej W. Rozycki wrote:
On Tue, 19 Sep 2006, Amy Fong wrote:
And... where are the users of this phy driver?
[...]
This phy driver is used by the WRS's sbc8560 (bcm5421s) and sbc843x
(bcm5461s) via the gianfar driver.
And sb1250-mac.c would be happy to use it too.
"would be happy to" !=
On Tue, 19 Sep 2006, Jeff Garzik wrote:
> > And sb1250-mac.c would be happy to use it too.
>
> "would be happy to" != "is using". I don't want to add a phy driver until
> there are already active users in the kernel.
Fair enough, but Amy may be looking forward to seeing yet another piece
of
From: "Vladimir B. Savkin" <[EMAIL PROTECTED]>
Date: Tue, 19 Sep 2006 02:03:31 +0400
> On Tue, Sep 19, 2006 at 02:00:38AM +0400, Alexey Kuznetsov wrote:
> > * I do see get_offset_pmtmr() in top lines of profile. That's scary enough.
>
> I had it at the very top line.
That is just rediculious.
Y
From: David Lang <[EMAIL PROTECTED]>
Date: Mon, 18 Sep 2006 14:57:04 -0700 (PDT)
> yes tcpdump may be wrong in requesting timestamps (in most cases it
> probably is, but in some cases it's doing exactly what the sysadmin
> wants it to do), but I don't think that many sysadmins would expect
> this
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Tue, 19 Sep 2006 02:00:38 +0400
> * I do not undestand what the hell dhcp needs timestamps for.
I can't even find a reference to SIOCGSTAMP in the
dhcp-2.0pl5 or dhcp3-3.0.3 sources shipped in Ubuntu.
But I will note that tpacket_rcv() expects to
The sky2 hardware (and others) can timestamp in hardware, but trying
to keep device ticks and system clock in sync looked too nasty
to contemplate actually using it.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
* David Miller <[EMAIL PROTECTED]> 2006-09-18 14:22
> From: Alexey Kuznetsov <[EMAIL PROTECTED]>
> Date: Tue, 19 Sep 2006 01:03:21 +0400
>
> > 1. It even does not disable possibility to record timestamp inside
> >driver, which Alan was afraid of. The sequence is:
> >
> > if (!skb->tstamp.
On Tue, 19 Sep 2006 22:25:21 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > - It took maybe ten hours solid work to get this dogpile vaguely
> > compiling and limping to a login prompt on x86, x86_64 and powerpc.
> > I guess it's worth briefly testing if you're keen.
>
> It's not t
> It seems only natural to me that the real problem is the slow
> clock source which needs to be resolved regardless of the
> outcome of this discussion. I believe that updating the stamp
> at socket enqueue time is the right thing to do but it shouldn't
> be considered as a solution to the perfor
On Tuesday, 19 September 2006 22:36, Andrew Morton wrote:
> On Tue, 19 Sep 2006 22:25:21 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > - It took maybe ten hours solid work to get this dogpile vaguely
> > > compiling and limping to a login prompt on x86, x86_64 and powerpc.
> >
From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
Date: Wed, 20 Sep 2006 00:06:52 +0200
> I _guess_ the problem is caused by
> gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> because the kernel (obviously) doesn't compile if I revert it.
Indeed.
I thought we threw this
On Tuesday, 19 September 2006 23:30, Rafael J. Wysocki wrote:
> On Tuesday, 19 September 2006 22:36, Andrew Morton wrote:
> > On Tue, 19 Sep 2006 22:25:21 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > > > - It took maybe ten hours solid work to get this dogpile vaguely
> > > >
On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> Date: Wed, 20 Sep 2006 00:06:52 +0200
>
> > I _guess_ the problem is caused by
> > gregkh-driver-network-class_device-to-device.patch, but I can't verify this,
> > because the kernel (ob
On Wednesday, 20 September 2006 00:30, Greg KH wrote:
> On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > Date: Wed, 20 Sep 2006 00:06:52 +0200
> >
> > > I _guess_ the problem is caused by
> > > gregkh-driver-network-class_device-to
On Tue, 19 Sep 2006 23:30:34 +0200, "Rafael J. Wysocki" said:
> Well, I can configure the interfaces manually, with ifconfig, but the SUSE's
> configuration tools don't work. For example, "ifup eth0" tells me that
> "No configuration found for eth0" and that's all.
I'm seeing issues on a Dell La
On Tuesday 19 September 2006 18:30, Greg KH wrote:
> On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > Date: Wed, 20 Sep 2006 00:06:52 +0200
> >
> > > I _guess_ the problem is caused by
> > > gregkh-driver-network-class_device-to-de
On Wed, Sep 20, 2006 at 12:56:57AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 20 September 2006 00:30, Greg KH wrote:
> > On Tue, Sep 19, 2006 at 03:06:29PM -0700, David Miller wrote:
> > > From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > > Date: Wed, 20 Sep 2006 00:06:52 +0200
> > >
> > > >
> WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text: from
> .text between 'he_start' (at offset 0x218a) and 'he_service_tbrq'
> -static int __init
> +static int __devinit
> he_init_group(struct he_dev *he_dev, int group)
There are a ton of other __init functions (he_ini
* Johannes Berg <[EMAIL PROTECTED]> 2006-09-14 11:21
> On Thu, 2006-09-14 at 10:14 +0200, Thomas Graf wrote:
>
> > Looks good, we have to watch the size of struct nla_policy though.
> > This bumps the size from 4 bytes to 16 bytes on 64bit architectures
> > which might become a problem since we al
* Johannes Berg <[EMAIL PROTECTED]> 2006-09-14 12:53
> This is some preliminary code how I'm currently thinking (and that might
> change radically :) ) configuration might look like.
>
> It uses the patch I previously posted to make genetlink attributes
> custom-definable.
>
> --- wireless-dev.or
Brian Haley wrote:
> Make some netfilter globals __read_mostly at the request of Patrick
> McHardy.
>
> Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
Applied, thanks Brian.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
Hi Andrew,
> From: Pavel Machek <[EMAIL PROTECTED]>
>
> This cleans up bluetooth a bit, no code changes.
NAK on this one. These cleanups will come with my other pending
cleanups.
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [E
When using ipsec while selinux is enabled in my kernel,
my racoon daemon fails to establish an SA. I believe the
ACQUIRE sent from kernel has a security context although I
am not using this feature with ipsec. As a result, racoon
fails to establish the SA, because it is looking for a policy
with
This doesn't look right since kzalloc would already have zeroed the
structure out. Are you sure you are getting garbage in the acquire
from the kernel? If you are, I strongly doubt that this would be the
one causing it (unless kzalloc on this arch misbehaved).
Or is this a racoon bug?
> -Origi
101 - 167 of 167 matches
Mail list logo
