Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Robert P. J. Day wrote:
On Fri, 31 Aug 2007, Randy Dunlap wrote:
On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
On 19/07/07 17:19, Robert P. J. Day wrote:
On Thu, 19 Jul 2007, Randy Dunlap wrote:
I think that Stefan means a patch to the kconfig source code,
not the the Kconfig files. Good luck. I'd still like to see it.
yes, i understand what he wanted now. as a first step (that
theoretically shouldn't change any behaviour), i'd patch the Kconfig
structure to add a new attribute ("maturity") which would be allowed
to be set to *exactly one* of a pre-defined set of values (say,
OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING). and that's
it, nothing more.
don't try to do anything with any of that just yet, just add the
infrastructure to support the (optional) association of a maturity
level with a config option. that's step one.
What about something like this? I'm not sure if the addition to sym_init
is desirable... I also had to prefix _ to the name for now otherwise it
conflicts badly with the current symbols. It probably should stop
"depends on _BROKEN" etc. too.
i'm sure i'm going to get shouted down here, but i really disagree
with "BROKEN" being considered a "maturity level". IMHO, things like
EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for
what i think are obvious reasons.
something like BROKEN, though, has *nothing* to do with maturity. a
feature can be any of those maturity levels, and simultaneously be
BROKEN. i consider BROKEN to be what i call a "status", and different
status levels might be the default of normal, or KIND_OF_FLAKY or
TOTALLY_BORKED -- that's where BROKEN would fit in.
BROKEN is definitely a maturity level. A more accurate description
would be BITROTTING perhaps. The code in question has passed through
bleeding -> experimental -> stable, and come out the other side.
In contrast, OBSOLETE and DEPRECATED reflect high-level status not code
quality/maturity.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 2/3]S2io: Support for add/delete/store/restore ethernet addresses
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 09:28:23 -0400 > Sreenivasa Honnur wrote: > > - Support to add/delete/store/restore 64 and 128 Ethernet addresses for > > Xframe I and Xframe II respectively. > > > > Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]> > > Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]> > > What is the purpose of this? We do not support more than one unicast > MAC address at present... Yes we do, the card can register with the card in ->set_rx_mode() or enable promiscuous mode if it has no alternate MAC facility. See netdev->uc_list. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 2/3]S2io: Support for add/delete/store/restore ethernet addresses
David Miller wrote: From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 09:28:23 -0400 Sreenivasa Honnur wrote: - Support to add/delete/store/restore 64 and 128 Ethernet addresses for Xframe I and Xframe II respectively. Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]> Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]> What is the purpose of this? We do not support more than one unicast MAC address at present... Yes we do, the card can register with the card in ->set_rx_mode() or enable promiscuous mode if it has no alternate MAC facility. See netdev->uc_list. Ah, well objection removed then. I stand corrected. Didn't know it was in yet. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/infiniband/hw/cxgb3/cxio_hal.c |2 +-
drivers/net/cxgb3/adapter.h|2 +
drivers/net/cxgb3/common.h |3 +-
drivers/net/cxgb3/cxgb3_main.c | 252 +++-
drivers/net/cxgb3/cxgb3_offload.c | 16 ++-
drivers/net/cxgb3/cxgb3_offload.h |2 +
drivers/net/cxgb3/sge.c| 23 ++-
drivers/net/cxgb3/t3_hw.c | 46 +-
drivers/net/cxgb3/t3cdev.h |3 -
drivers/net/ioc3-eth.c | 80 ---
drivers/net/netxen/netxen_nic_hdr.h|6 +-
drivers/net/netxen/netxen_nic_hw.c |8 +-
drivers/net/netxen/netxen_nic_main.c | 19 +--
drivers/net/ps3_gelic_net.c|1 -
drivers/s390/net/qeth.h|4 +-
drivers/s390/net/qeth_main.c | 158 +++-
drivers/s390/net/qeth_mpc.h|1 +
drivers/s390/net/qeth_sys.c|8 +-
18 files changed, 428 insertions(+), 206 deletions(-)
Divy Le Ray (2):
cxgb3 - Fix dev->priv usage
- cxgb3 engine microcode load
Frank Blaschka (2):
qeth: enforce a rate limit for inbound scatter gather messages
qeth: Announce tx checksumming for qeth devices in TSO/EDDP mode
Heiko Carstens (1):
qeth: dont return the return values of void functions.
Klaus D. Wacker (1):
qeth: Drop ARP packages on HiperSockets interface with NOARP attribute.
Masakazu Mokuno (1):
PS3: fix the bug that 'ifconfig down' would hang
Ralf Baechle (1):
IOC3: Program UART predividers.
Ursula Braun (3):
qeth: ungrouping a device must not be interruptible
qeth: crash during reboot after failing online setting
qeth: provide specific message for OSA-adapters exclusively used
[EMAIL PROTECTED] (2):
netxen: Avoid firmware load in PCI probe
netxen: fix crashes during module unload
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c
b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index 1518b41..beb2a38 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -916,7 +916,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
PDBG("%s opening rnic dev %s\n", __FUNCTION__, rdev_p->dev_name);
memset(&rdev_p->ctrl_qp, 0, sizeof(rdev_p->ctrl_qp));
if (!rdev_p->t3cdev_p)
- rdev_p->t3cdev_p = T3CDEV(netdev_p);
+ rdev_p->t3cdev_p = dev2t3cdev(netdev_p);
rdev_p->t3cdev_p->ulp = (void *) rdev_p;
err = rdev_p->t3cdev_p->ctl(rdev_p->t3cdev_p, RDMA_GET_PARAMS,
&(rdev_p->rnic_info));
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
index ab72563..20e887d 100644
--- a/drivers/net/cxgb3/adapter.h
+++ b/drivers/net/cxgb3/adapter.h
@@ -50,7 +50,9 @@ typedef irqreturn_t(*intr_handler_t) (int, void *);
struct vlan_group;
+struct adapter;
struct port_info {
+ struct adapter *adapter;
struct vlan_group *vlan_grp;
const struct port_type_info *port_type;
u8 port_id;
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 1637800..2129210 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -679,7 +679,8 @@ const struct adapter_info *t3_get_adapter_info(unsigned int
board_id);
int t3_seeprom_read(struct adapter *adapter, u32 addr, u32 *data);
int t3_seeprom_write(struct adapter *adapter, u32 addr, u32 data);
int t3_seeprom_wp(struct adapter *adapter, int enable);
-int t3_check_tpsram_version(struct adapter *adapter);
+int t3_get_tp_version(struct adapter *adapter, u32 *vers);
+int t3_check_tpsram_version(struct adapter *adapter, int *must_load);
int t3_check_tpsram(struct adapter *adapter, u8 *tp_ram, unsigned int size);
int t3_set_proto_sram(struct adapter *adap, u8 *data);
int t3_read_flash(struct adapter *adapter, unsigned int addr,
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index dc5d269..5ab319c 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -358,11 +358,14 @@ static int init_dummy_netdevs(struct adapter *adap)
for (j = 0; j < pi->nqsets - 1; j++) {
if (!adap->dummy_netdev[dummy_idx]) {
- nd = alloc_netdev(0, "", ether_setup);
+ struct port_info *p;
+
+ nd = alloc_netdev(sizeof(*p), "", ether_setup);
if (!nd)
goto free_all;
- nd->priv = adap;
+ p = netdev_priv(nd);
+ p->adapter = adap;
nd->weight = 64;
set_b
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 31 Aug 2007 11:11:37 -0700
> At the risk of showing my ignorance (what me worry about that?-) I
> presume this is then an interface expecting to take-in jiffies? That
> means the user has to know the value of HZ which can be (IIRC) one of
> three different values?
The iproute2 changes might look something like this:
--- ./include/linux/rtnetlink.h.orig2007-08-31 11:55:30.0 -0700
+++ ./include/linux/rtnetlink.h 2007-08-31 11:52:22.0 -0700
@@ -351,6 +351,8 @@ enum
#define RTAX_INITCWND RTAX_INITCWND
RTAX_FEATURES,
#define RTAX_FEATURES RTAX_FEATURES
+ RTAX_RTO_MIN,
+#define RTAX_RTO_MIN RTAX_RTO_MIN
__RTAX_MAX
};
--- ./ip/iproute.c.orig 2007-08-31 11:55:30.0 -0700
+++ ./ip/iproute.c 2007-08-31 11:53:29.0 -0700
@@ -51,6 +51,7 @@ static const char *mx_names[RTAX_MAX+1]
[RTAX_HOPLIMIT] = "hoplimit",
[RTAX_INITCWND] = "initcwnd",
[RTAX_FEATURES] = "features",
+ [RTAX_RTO_MIN] = "rto_min",
};
static void usage(void) __attribute__((noreturn));
@@ -74,6 +75,7 @@ static void usage(void)
fprintf(stderr, " [ rtt NUMBER ] [ rttvar NUMBER ]\n");
fprintf(stderr, " [ window NUMBER] [ cwnd NUMBER ] [ initcwnd
NUMBER ]\n");
fprintf(stderr, " [ ssthresh NUMBER ] [ realms REALM ]\n");
+ fprintf(stderr, " [ rto_min NUMBER ]\n");
fprintf(stderr, "TYPE := [ unicast | local | broadcast | multicast |
throw |\n");
fprintf(stderr, " unreachable | prohibit | blackhole | nat
]\n");
fprintf(stderr, "TABLE_ID := [ local | main | default | all | NUMBER
]\n");
@@ -520,7 +522,8 @@ int print_route(const struct sockaddr_nl
if (mxlock & (1<= hz)
fprintf(fp, " %ums", val/hz);
@@ -803,6 +806,15 @@ int iproute_modify(int cmd, unsigned fla
if (get_unsigned(&rtt, *argv, 0))
invarg("\"rtt\" value is invalid\n", *argv);
rta_addattr32(mxrta, sizeof(mxbuf), RTAX_RTT, rtt);
+ } else if (strcmp(*argv, "rto_min") == 0) {
+ unsigned rto_min;
+ NEXT_ARG();
+ mxlock |= (1
Re: net-2.6.24 rebased
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 09:44:32 -0400 > Sorry, I sent the patch through Jeff. > > > http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik/0010-rtl8187-remove-IEEE80211_HW_DATA_NULLFUNC_ACK.patch > > But, it sounds like you have taken care of it...? > > Let me know if I need to fix this. Thanks for tracking this down, that is exactly the change I checked into 2.6.24 so everything is good now. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Aug 31 2007 14:06, Jeff Garzik wrote: >> something like BROKEN, though, has *nothing* to do with maturity. a >> feature can be any of those maturity levels, and simultaneously be >> BROKEN. i consider BROKEN to be what i call a "status", and different >> status levels might be the default of normal, or KIND_OF_FLAKY or >> TOTALLY_BORKED -- that's where BROKEN would fit in. > > BROKEN is definitely a maturity level. A more accurate description would be > BITROTTING perhaps. The code in question has passed through bleeding -> > experimental -> stable, and come out the other side. Software is quite unlike the art of medicine. There, you would go from 'stable' to 'broken', then someone 'experiments' with you, and if it's a bad day, you bleed out. :) Jan -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007 14:06:33 -0400 Jeff Garzik wrote:
> Robert P. J. Day wrote:
> > On Fri, 31 Aug 2007, Randy Dunlap wrote:
> >
> >> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
> >>
> >>> On 19/07/07 17:19, Robert P. J. Day wrote:
> On Thu, 19 Jul 2007, Randy Dunlap wrote:
> > I think that Stefan means a patch to the kconfig source code,
> > not the the Kconfig files. Good luck. I'd still like to see it.
> yes, i understand what he wanted now. as a first step (that
> theoretically shouldn't change any behaviour), i'd patch the Kconfig
> structure to add a new attribute ("maturity") which would be allowed
> to be set to *exactly one* of a pre-defined set of values (say,
> OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING). and that's
> it, nothing more.
>
> don't try to do anything with any of that just yet, just add the
> infrastructure to support the (optional) association of a maturity
> level with a config option. that's step one.
> >>> What about something like this? I'm not sure if the addition to sym_init
> >>> is desirable... I also had to prefix _ to the name for now otherwise it
> >>> conflicts badly with the current symbols. It probably should stop
> >>> "depends on _BROKEN" etc. too.
> >
> > i'm sure i'm going to get shouted down here, but i really disagree
> > with "BROKEN" being considered a "maturity level". IMHO, things like
> > EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for
> > what i think are obvious reasons.
> >
> > something like BROKEN, though, has *nothing* to do with maturity. a
> > feature can be any of those maturity levels, and simultaneously be
> > BROKEN. i consider BROKEN to be what i call a "status", and different
> > status levels might be the default of normal, or KIND_OF_FLAKY or
> > TOTALLY_BORKED -- that's where BROKEN would fit in.
>
> BROKEN is definitely a maturity level. A more accurate description
> would be BITROTTING perhaps. The code in question has passed through
> bleeding -> experimental -> stable, and come out the other side.
>
> In contrast, OBSOLETE and DEPRECATED reflect high-level status not code
> quality/maturity.
What I like about the patch is that it associates some kconfig symbol
with prompt strings, so that we don't have to edit "(EXPERIMENTAL)"
all the darn time (e.g.).
I'd be quite happy with calling it "status" rather than "maturity",
and with being able to use multiple of the status tags at one time,
such as
config FOO
depends on BAR
status OBSOLETE BROKEN
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix e100 on systems that have cache incoherent DMA
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next link equal to 0.
When hardware encounters this buffer it attempts to write data to it and
then update Status Word bits and Actual Count in the RFD. At the same time
software may try to clear the el-bit and set the link address to a new buffer.
Since the entire RFD is once cache-line, the two write operations can collide.
This can lead to the receive unit stalling or interpreting random memory as
its receive area.
The fix is to set the el-bit on and the size to 0 on the next to last buffer
in the chain. When the hardware encounters this buffer it stops and does not
write to it at all. The hardware issues an RNR interrupt with the receive
unit in the No Resources state. Software can write to the tail of the list
because it knows hardware will stop on the previous descriptor that was
marked as the end of list.
Once it has a new next to last buffer prepared, it can clear the el-bit and
set the size on the previous one. The race on this buffer is safe since
the link already points to a valid next buffer and the software can handle
the race setting the size (assuming aligned 16 bit writes are atomic with
respect to the DMA read). If the hardware sees the el-bit cleared without
the size set, it will move on to the next buffer and skip this one. If it
sees the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
Flags are kept in the software descriptor to note if the el bit is set and if
the size was 0. When software clears the RFD's el bit and set its size, it
also clears the el flag but leaves the size was 0 bit set. This way software
can identify them when the race may have occurred when cleaning the ring.
On these descriptors, it looks ahead and if the next one is complete then
hardware must have skipped the current one. Logic is added to prevent two
packets in a row being marked while the receiver is running to avoid running
in lockstep with the hardware and thereby limiting the required lookahead.
This is a patch for 2.6.23-rc4.
Signed-off-by: David Acker <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc4/drivers/net/e100.c.orig2007-08-30 13:32:10.0
-0400
+++ linux-2.6.23-rc4/drivers/net/e100.c 2007-08-30 15:42:07.0 -0400
@@ -106,6 +106,13 @@
* the RFD, the RFD must be dma_sync'ed to maintain a consistent
* view from software and hardware.
*
+ * In order to keep updates to the RFD link field from colliding with
+ * hardware writes to mark packets complete, we use the feature that
+ * hardware will not write to a size 0 descriptor and mark the previous
+ * packet as end-of-list (EL). After updating the link, we remove EL
+ * and only then restore the size such that hardware may use the
+ * previous-to-end RFD.
+ *
* Under typical operation, the receive unit (RU) is start once,
* and the controller happily fills RFDs as frames arrive. If
* replacement RFDs cannot be allocated, or the RU goes non-active,
@@ -281,14 +288,14 @@ struct csr {
};
enum scb_status {
+ rus_no_res = 0x08,
rus_ready= 0x10,
rus_mask = 0x3C,
};
enum ru_state {
- RU_SUSPENDED = 0,
- RU_RUNNING = 1,
- RU_UNINITIALIZED = -1,
+ ru_stopped = 0,
+ ru_running = 1,
};
enum scb_stat_ack {
@@ -401,10 +408,16 @@ struct rfd {
u16 size;
};
+enum rx_flags {
+ rx_el = 0x01,
+ rx_s0 = 0x02,
+};
+
struct rx {
struct rx *next, *prev;
struct sk_buff *skb;
dma_addr_t dma_addr;
+ u8 flags;
};
#if defined(__BIG_ENDIAN_BITFIELD)
@@ -952,7 +965,7 @@ static void e100_get_defaults(struct nic
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic->blank_rfd.command = cpu_to_le16(cb_el);
+ nic->blank_rfd.command = 0;
nic->blank_rfd.rbd = 0x;
nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1753,18 +1766,48 @@ static int e100_alloc_cbs(struct nic *ni
return 0;
}
-static inline void e100_start_receiver(struct nic *nic, struct rx *rx)
+static void e100_find_mark_el(struct nic *nic, struct rx *marked_rx, int
is_running)
{
- if(!nic->rxs) return;
- if(RU_SUSPENDED != nic->ru_running) return;
+ struct rx *rx = nic->rx_to_use->prev->prev;
+ struct rfd *rfd;
+
+ if (marked_rx == rx)
+ return;
+
+ rfd = (struct rfd *) rx->skb->data;
+ rfd->command |= cpu_to_le16(cb_el);
+ rfd->size = 0;
+ pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
+ sizeof(struct rfd), PCI_DMA_BIDIRECTIONAL);
+ rx->flags |= (
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
I managed to find iproute2 sources (they were debian lenny/testing 2.6.20-1) and applied the patch, and figured-out how to add a host route back to one of my systems. I then did a change to set rto_min to 300. I started a tcpdump and then a netperf, and then forces some retransmissions the old fashioned way - by pulling a cable :) I then Ctrl-C'd netperf and at that point got this: Unable to handle kernel NULL pointer dereference (address 0038) swapper[0]: Oops 8813272891392 [1] Modules linked in: ipv6 sg sr_mod cdrom dm_snapshot dm_mirror dm_mod loop button shpchp pci_hotplug joydev evdev ext3 jbd mbcache usb_storage usbhid hid ide_core mptspi mptscsih ehci_hcd cciss ohci_hcd mptbase scsi_transport_spi scsi_mod usbcore e1000 thermal processor fan Pid: 0, CPU 3, comm: swapper psr : 101008026038 ifs : 8001 ip : [] Not tainted ip is at tcp_rto_min+0x20/0x40 unat: pfs : 0307 rsc : 0003 rnat: e100f32917e0 bsps: e100f32917e8 pr : 000166a5 ldrs: ccv : 00010001 fpsr: 0009804c0270033f csd : ssd : b0 : a001004777f0 b6 : a00100230700 b7 : a00100452e40 f6 : 0 f7 : 1003e0002813f f8 : 1003e001c06e2 f9 : 1003e043f f10 : 1003e000fd24b f11 : 1003e0044b82fa09b5a53 r1 : a001009b2710 r2 : r3 : e100fd317b40 r8 : 0032 r9 : 012c r10 : 0003 r11 : e00ff07b63a0 r12 : e100fd317b40 r13 : e100fd31 r14 : r15 : 0038 r16 : 0068 r17 : e00ff07b6380 r18 : fa58 r19 : 8d769671 r20 : 8d769c19 r21 : e00ff07b62f0 r22 : 8d7712e1 r23 : e00ff07b62ec r24 : e00ff07b637c r25 : 012c r26 : 0032 r27 : e00ff07b6438 r28 : e00ff07b5fc8 r29 : e00ff215bd80 r30 : e00ff07b60d0 r31 : e00ff07b6250 Call Trace: [] show_stack+0x40/0xa0 sp=e100fd317710 bsp=e100fd311310 [] show_regs+0x840/0x880 sp=e100fd3178e0 bsp=e100fd3112b8 [] die+0x1a0/0x2a0 sp=e100fd3178e0 bsp=e100fd311270 [] ia64_do_page_fault+0x8d0/0xa00 sp=e100fd3178e0 bsp=e100fd311220 [] ia64_leave_kernel+0x0/0x270 sp=e100fd317970 bsp=e100fd311220 [] tcp_rto_min+0x20/0x40 sp=e100fd317b40 bsp=e100fd311218 [] tcp_rtt_estimator+0x1d0/0x280 sp=e100fd317b40 bsp=e100fd3111e0 [] tcp_ack_saw_tstamp+0x50/0xc0 sp=e100fd317b40 bsp=e100fd3111c0 [] tcp_ack+0x13c0/0x4380 sp=e100fd317b40 bsp=e100fd311120 [] tcp_rcv_state_process+0x1420/0x2100 sp=e100fd317b60 bsp=e100fd3110d8 [] tcp_v4_do_rcv+0x960/0xa80 sp=e100fd317b60 bsp=e100fd311078 [] tcp_v4_rcv+0x19d0/0x1b20 sp=e100fd317b70 bsp=e100fd311008 [] ip_local_deliver+0x530/0x7c0 sp=e100fd317b70 bsp=e100fd310fd0 [] ip_rcv+0xe70/0xf80 sp=e100fd317b80 bsp=e100fd310f98 [] netif_receive_skb+0xa20/0xb80 sp=e100fd317ba0 bsp=e100fd310f50 [] e1000_clean_rx_irq+0x9e0/0xc00 [e1000] sp=e100fd317ba0 bsp=e100fd310e90 [] e1000_clean+0x130/0x6e0 [e1000] sp=e100fd317ba0 bsp=e100fd310e38 [] net_rx_action+0x1c0/0x540 sp=e100fd317bb0 bsp=e100fd310df0 [] __do_softirq+0xf0/0x240 sp=e100fd317bc0 bsp=e100fd310d78 [] do_softirq+0x70/0xc0 sp=e100fd317bc0 bsp=e100fd310d18 [] irq_exit+0x80/0xa0 sp=e100fd317bc0 bsp=e100fd310d00 [] ia64_handle_irq+0x2a0/0x2e0 sp=e100fd317bc0 bsp=e100fd310cd0 [] ia64_leave_kernel+0x0/0x270 sp=e100fd317bc0 bsp=e100fd310cd0 [] default_idle+0x110/0x180 sp=e100fd317d90 bsp=e100fd310c90 [] cpu_idle+0x210/0x2e0 sp=e100fd317e30 bsp=e100fd310c60 [] start_secondary+0x4b0/0x4e0 sp=e100fd317e30 bsp=e100fd310c20 [] __kprobes_text_end+0x340/0x370 sp=e100fd317e30 bsp=e100fd310c20 Kernel panic - not syncing: Aiee, killing interrupt handler! Of course there isn't all that much code to tcp_rto_min: +static u32 tcp_rto_min(struct sock *s
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Jeff Garzik wrote: > Robert P. J. Day wrote: > > i'm sure i'm going to get shouted down here, but i really disagree > > with "BROKEN" being considered a "maturity level". IMHO, things > > like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity > > levels, for what i think are obvious reasons. > > > > something like BROKEN, though, has *nothing* to do with maturity. > > a feature can be any of those maturity levels, and simultaneously > > be BROKEN. i consider BROKEN to be what i call a "status", and > > different status levels might be the default of normal, or > > KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit > > in. > > BROKEN is definitely a maturity level. no. it's not. end of discussion. you're wrong. the concept of "maturity level" reflects where in the life cycle some feature is. it will typically start as "bleeding edge" or "experimental" or something like that, eventually stabilize to be normal (which would be the obvious default), after which, when its value starts to run out and it begins showing its age, it becomes "deprecated" and eventually "obsolete" it's a natural and obvious progression. on the other hand, a feature can be "broken" at *any* point in that life cycle -- that's why it is absolutely *not* a maturity level. please don't fight with me on this, jeff. you're simply wrong. > In contrast, OBSOLETE and DEPRECATED reflect high-level status not > code quality/maturity. you have this so backwards, i can't begin to think how to explain it to you. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Randy Dunlap wrote: > What I like about the patch is that it associates some kconfig > symbol with prompt strings, so that we don't have to edit > "(EXPERIMENTAL)" all the darn time (e.g.). > > I'd be quite happy with calling it "status" rather than "maturity", > and with being able to use multiple of the status tags at one time, > such as > > config FOO > depends on BAR > status OBSOLETE BROKEN g ... i already made my point in my earlier post. i'd really, really like it if *this* attribute remained as "maturity". an entirely *separate* attribute could be defined as a feature "status", which would be entirely orthogonal to maturity level, so that the above would be written as maturity OBSOLETE status BROKEN there's a reason for this -- any feature should have exactly *one* value for any attribute. that is, in terms of maturity, a feature could be EXPERIMENTAL *or* DEPRECATED *or* OBSOLETE. it ***can't*** be more than one, as in both DEPRECATED *and* OBSOLETE. to allow that flexibility is to descend into absurdity. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007 17:00:57 -0400 (EDT) Robert P. J. Day wrote: > On Fri, 31 Aug 2007, Randy Dunlap wrote: > > > What I like about the patch is that it associates some kconfig > > symbol with prompt strings, so that we don't have to edit > > "(EXPERIMENTAL)" all the darn time (e.g.). > > > > I'd be quite happy with calling it "status" rather than "maturity", > > and with being able to use multiple of the status tags at one time, > > such as > > > > config FOO > > depends on BAR > > status OBSOLETE BROKEN > > g ... i already made my point in my earlier post. i'd > really, really like it if *this* attribute remained as "maturity". an > entirely *separate* attribute could be defined as a feature "status", > which would be entirely orthogonal to maturity level, so that the > above would be written as > > maturity OBSOLETE > status BROKEN > > there's a reason for this -- any feature should have exactly *one* > value for any attribute. that is, in terms of maturity, a feature > could be EXPERIMENTAL *or* DEPRECATED *or* OBSOLETE. it ***can't*** > be more than one, as in both DEPRECATED *and* OBSOLETE. to allow that > flexibility is to descend into absurdity. If Simon (or anyone else) continues to work on it, I'll leave this decision up to them... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
From: Rick Jones <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 13:59:50 -0700 > ip is at tcp_rto_min+0x20/0x40 diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 1ee7212..bbad2cd 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; - if (dst_metric_locked(dst, RTAX_RTO_MIN)) + if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst->metrics[RTAX_RTO_MIN-1]; return rto_min; } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2][BNX2]: Add iSCSI support to BNX2 devices.
Third version of the iSCSI patch for BNX2 which has addressed the comments we have received. I know there is general dislike about this stuff on netdev, as shown by the RDMA discussions. iSCSI is at least a bit more mainstream. David, please consider merging this for 2.6.24. Thanks. Full patch available from ftp: ftp://[EMAIL PROTECTED]/0003-BNX2-Add-iSCSI-support-to-BNX2-devices.patch Firmware blob omitted in the next 2 emails for review. -- [BNX2]: Add iSCSI support to BNX2 devices. Modify bnx2 and add a cnic driver to support some offload functions needed by iSCSI. Add a new open-iscsi driver to support iSCSI offload on bnx2 devices. Signed-off-by: Anil Veerabhadrappa <[EMAIL PROTECTED]> Signed-off-by: Michael Chan <[EMAIL PROTECTED]> --- drivers/net/Kconfig | 10 + drivers/net/Makefile |1 + drivers/net/bnx2.c| 117 +- drivers/net/bnx2.h| 21 +- drivers/net/bnx2_fw.h | 7039 ++--- drivers/net/cnic.c| 1881 drivers/net/cnic.h| 163 + drivers/net/cnic_cm.h | 555 +++ drivers/net/cnic_if.h | 152 + drivers/scsi/Kconfig |2 + drivers/scsi/Makefile |1 + drivers/scsi/bnx2i/57xx_iscsi_constants.h | 212 + drivers/scsi/bnx2i/57xx_iscsi_hsi.h | 1501 ++ drivers/scsi/bnx2i/Kconfig|7 + drivers/scsi/bnx2i/Makefile |4 + drivers/scsi/bnx2i/bnx2i.h| 841 drivers/scsi/bnx2i/bnx2i_hwi.c| 1977 drivers/scsi/bnx2i/bnx2i_init.c | 400 ++ drivers/scsi/bnx2i/bnx2i_iscsi.c | 3578 +++ drivers/scsi/bnx2i/bnx2i_sysfs.c | 615 +++ 20 files changed, 16440 insertions(+), 2637 deletions(-) create mode 100644 drivers/net/cnic.c create mode 100644 drivers/net/cnic.h create mode 100644 drivers/net/cnic_cm.h create mode 100644 drivers/net/cnic_if.h create mode 100644 drivers/scsi/bnx2i/57xx_iscsi_constants.h create mode 100644 drivers/scsi/bnx2i/57xx_iscsi_hsi.h create mode 100644 drivers/scsi/bnx2i/Kconfig create mode 100644 drivers/scsi/bnx2i/Makefile create mode 100644 drivers/scsi/bnx2i/bnx2i.h create mode 100644 drivers/scsi/bnx2i/bnx2i_hwi.c create mode 100644 drivers/scsi/bnx2i/bnx2i_init.c create mode 100644 drivers/scsi/bnx2i/bnx2i_iscsi.c create mode 100644 drivers/scsi/bnx2i/bnx2i_sysfs.c - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Ethernet weirdness on 82xx
I'm not sure if this is by design or an actual bug. We have a system witb an 8280 with two active ethernets (fcc2 and fcc3) We are running kernel 2.6.18.1 (and won't be upgrading in a while) out of arch/ppc Eth0 and eth1 are in totally different subnets. We happened to have both ehternets connected to the same network, and I ran a arping agains the IP on eth0. Both ports (eth0 and eth1) responded with the same address, but different macs sudo /sbin/arping -c1 172.23.12.114 ARPING 172.23.12.114 from 172.23.15.21 eth0 Unicast reply from 172.23.12.114 [00:30:D7:00:14:55] 0.838ms Unicast reply from 172.23.12.114 [00:30:D7:00:14:54] 0.890ms Sent 1 probes (1 broadcast(s)) Received 2 response(s) It only gets both responses on the first (broadcast) query from arping All responses afterward is then from the wrong port The ethernet setup on the target box: eth0 Link encap:Ethernet HWaddr 00:30:D7:00:14:54 inet addr:172.23.12.114 Bcast:172.23.15.255 Mask:255.255.248.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:473244 errors:0 dropped:2 overruns:0 frame:0 TX packets:186655 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:162928671 (155.3 Mb) TX bytes:4862 (40.2 Mb) Base address:0x8500 eth1 Link encap:Ethernet HWaddr 00:30:D7:00:14:55 inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1553 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:203182 (198.4 Kb) TX bytes:168 (168.0 b) Base address:0x8600 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/1] Block device throttling [Re: Distributed storage.]
On Thu, Aug 30, 2007 at 04:20:35PM -0700, Daniel Phillips wrote: > Resubmitting a bio or submitting a dependent bio from > inside a block driver does not need to be throttled because all > resources required to guarantee completion must have been obtained > _before_ the bio was allowed to proceed into the block layer. I'm toying with the idea of keeping track of the maximum device stack depth for each stacked device, and only permitting it to increase in controlled circumstances. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Robert P. J. Day wrote: On Fri, 31 Aug 2007, Jeff Garzik wrote: Robert P. J. Day wrote: i'm sure i'm going to get shouted down here, but i really disagree with "BROKEN" being considered a "maturity level". IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons. something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a "status", and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in. BROKEN is definitely a maturity level. no. it's not. end of discussion. you're wrong. the concept of "maturity level" reflects where in the life cycle some feature is. it will typically start as "bleeding edge" or "experimental" or something like that, eventually stabilize to be normal (which would be the obvious default), after which, when its value starts to run out and it begins showing its age, it becomes "deprecated" and eventually "obsolete" it's a natural and obvious progression. on the other hand, a feature can be "broken" at *any* point in that life cycle -- that's why it is absolutely *not* a maturity level. please don't fight with me on this, jeff. you're simply wrong. Get off your high horse and actually look at the patches that mark things BROKEN. 'deprecrated' and 'obsolete' are matters of discussed opinion, describing the utility of the code in question. 'broken' describes the state of the code itself. Clear difference. Jeff, one who actually marks this stuff as such - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
On Tue, 2007-08-28 at 14:22 -0700, David Miller wrote:
> From: Joe Perches <[EMAIL PROTECTED]>
> > Option 2:
> > DECLARE_MAC_BUF(mac);
> > printk("%s", print_mac(mac, dev->dev_addr));
> I'm slightly leaning towards 2.
Here are the patches for this conversion.
Compiled successfully x86, defconfig and allyesconfig
against net-2.6.24 but the patch is largely untested.
I've inlined the include changes, but the entire patch
is quite large. (300KB)
MAC address format changes:
UPPER->lower case changes in MAC addresses in printks.
presentation from "%x %x..." to "%02x:%02x...".
seq_printf uses of mac addresses
Perhaps the seq_printf changes might cause problems
with usermode programs.
please pull from:
git pull git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-print_mac
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
--
include/linux/if_ether.h |7 +++
include/net/ieee80211.h |5 -
include/net/mac80211.h |4
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index 3213f6f..bb3eb51 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -122,4 +122,11 @@ extern struct ctl_table ether_table[];
#endif
#endif
+/*
+ * Display a 6 byte device address (MAC) in a readable format.
+ */
+#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
+extern char *print_mac(char* buf, const u8 *addr);
+#define DECLARE_MAC_BUF(var) char var[18] __maybe_unused
+
#endif /* _LINUX_IF_ETHER_H */
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index bbd85cd..164d132 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -119,11 +119,6 @@ do { if (ieee80211_debug_level & (level)) \
#define IEEE80211_DEBUG(level, fmt, args...) do {} while (0)
#endif /* CONFIG_IEEE80211_DEBUG */
-/* debug macros not dependent on CONFIG_IEEE80211_DEBUG */
-
-#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
-#define MAC_ARG(x)
((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5]
-
/* escape_essid() is intended to be used in debug (and possibly error)
* messages. It should never be used for passing essid to user space. */
const char *escape_essid(const char *essid, u8 essid_len);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ec8c739..6de3ceb 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1089,8 +1089,4 @@ static inline int ieee80211_get_morefrag(struct
ieee80211_hdr *hdr)
IEEE80211_FCTL_MOREFRAGS) != 0;
}
-#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
-#define MAC_ARG(x) ((u8*)(x))[0], ((u8*)(x))[1], ((u8*)(x))[2], \
- ((u8*)(x))[3], ((u8*)(x))[4], ((u8*)(x))[5]
-
#endif /* MAC80211_H */
--
drivers/net/3c503.c |4 +-
drivers/net/3c505.c | 10 +-
drivers/net/3c507.c |6 +-
drivers/net/3c509.c |6 +-
drivers/net/3c515.c |4 +-
drivers/net/3c523.c | 20 +--
drivers/net/3c527.c |7 +-
drivers/net/3c59x.c |7 +-
drivers/net/8139cp.c |8 +-
drivers/net/8139too.c |8 +-
drivers/net/82596.c | 18 +--
drivers/net/a2065.c |6 +-
drivers/net/ac3200.c |8 +-
drivers/net/acenic.c |7 +-
drivers/net/amd8111e.c| 12 +-
drivers/net/apne.c|9 +-
drivers/net/ariadne.c | 44 +++---
drivers/net/arm/am79c961a.c |8 +-
drivers/net/arm/at91_ether.c | 18 +-
drivers/net/arm/ether1.c |8 +-
drivers/net/arm/ether3.c |8 +-
drivers/net/arm/etherh.c |8 +-
drivers/net/at1700.c |4 +-
drivers/net/atarilance.c | 40 +++---
drivers/net/atp.c |8 +-
drivers/net/b44.c |9 +-
drivers/net/bmac.c|6 +-
drivers/net/bnx2.c| 12 +-
drivers/net/bonding/bond_main.c | 34 ++---
drivers/net/bonding/bond_sysfs.c | 11 +-
drivers/net/cassini.c | 11 +-
drivers/net/cris/eth_v10.c|8 +-
drivers/net/cs89x0.c | 15 +--
drivers/net/de600.c |6 +-
drivers/net/de620.c |8 +-
drivers/net/declance.c| 14 +-
drivers/net/depca.c | 13 +-
drivers/net/dgrs.c| 18 +--
drivers/net/dl2k.c
Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
On Fri, 2007-08-31 at 15:16 -0700, Joe Perches wrote: > please pull from: > git pull git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-print_mac got a gitweb for that somewhere? johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
David Miller wrote: From: Rick Jones <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 13:59:50 -0700 ip is at tcp_rto_min+0x20/0x40 diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 1ee7212..bbad2cd 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; - if (dst_metric_locked(dst, RTAX_RTO_MIN)) + if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst->metrics[RTAX_RTO_MIN-1]; return rto_min; } Applied and beating on it with a while loop doing a bunch of ip route del add change stuff while netperf TCP_CRR tests are running. Thusfar things seem OK wrt the system staying alive, but since I only saw the failure once I'm not sure how much that is really saying. I'm going to go ahead and take a look at input vs output units and differences between those with rto_min vs rtt. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Jeff Garzik wrote: > 'deprecrated' and 'obsolete' are matters of discussed opinion, > describing the utility of the code in question. 'broken' describes > the state of the code itself. > > Clear difference. precisely. thank you for making my point for me. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
On Sat, 2007-09-01 at 00:21 +0200, Johannes Berg wrote: > On Fri, 2007-08-31 at 15:16 -0700, Joe Perches wrote: > > please pull from: > > git pull git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-print_mac > got a gitweb for that somewhere? Does this work for you? http://repo.or.cz/w/linux-2.6/trivial-mods.git - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
From: Rick Jones <[EMAIL PROTECTED]> Date: Fri, 31 Aug 2007 15:20:52 -0700 > I'm going to go ahead and take a look at input vs output units and > differences between those with rto_min vs rtt. You better because that's one of the last non-trivial emails you'll get for me over the next few days while I'm travelling to kernel summit :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
On Fri, 2007-08-31 at 15:24 -0700, Joe Perches wrote: > On Sat, 2007-09-01 at 00:21 +0200, Johannes Berg wrote: > > On Fri, 2007-08-31 at 15:16 -0700, Joe Perches wrote: > > > please pull from: > > > git pull git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-print_mac > > got a gitweb for that somewhere? > > Does this work for you? > > http://repo.or.cz/w/linux-2.6/trivial-mods.git Perfect, thanks. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
On Fri, 2007-08-31 at 15:24 -0700, Joe Perches wrote: > On Sat, 2007-09-01 at 00:21 +0200, Johannes Berg wrote: > > On Fri, 2007-08-31 at 15:16 -0700, Joe Perches wrote: > > > please pull from: > > > git pull git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-print_mac > > got a gitweb for that somewhere? > > Does this work for you? > > http://repo.or.cz/w/linux-2.6/trivial-mods.git I think you got a bit too trigger-happy: p += sprintf(p, "key[%d] alg=CCMP key_set=%d " -"tx_pn=%02x%02x%02x%02x%02x%02x " -"rx_pn=%02x%02x%02x%02x%02x%02x " +"tx_pn=%s " +"rx_pn=%s " "format_errors=%d replays=%d decrypt_errors=%d\n", ccmp->key_idx, ccmp->key_set, -MAC_ARG(ccmp->tx_pn), MAC_ARG(ccmp->rx_pn), +print_mac(mac, ccmp->tx_pn), print_mac(mac2, ccmp->rx_pn), the PN is a number, not a MAC address :) The fact that it used MAC_ARG, was, I guess, just laziness of the original author since the PN is also 6 bytes long. That said, I can live with it being printed this way too, it's just a bit weird. Going to be fun to merge with my 70 outstanding patches though :) johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
On Sat, 2007-09-01 at 00:32 +0200, Johannes Berg wrote: > I think you got a bit too trigger-happy: > p += sprintf(p, "key[%d] alg=CCMP key_set=%d " > -"tx_pn=%02x%02x%02x%02x%02x%02x " > -"rx_pn=%02x%02x%02x%02x%02x%02x " > +"tx_pn=%s " > +"rx_pn=%s " > "format_errors=%d replays=%d decrypt_errors=%d\n", > ccmp->key_idx, ccmp->key_set, > -MAC_ARG(ccmp->tx_pn), MAC_ARG(ccmp->rx_pn), > +print_mac(mac, ccmp->tx_pn), print_mac(mac2, > ccmp->rx_pn), > > the PN is a number, not a MAC address :) The fact that it used MAC_ARG, > was, I guess, just laziness of the original author since the PN is also > 6 bytes long. That said, I can live with it being printed this way too, > it's just a bit weird. Yes, that was one of the dodgy ones. I didn't actually realize it wasn't a MAC address though. I think all of the sprintf/seq_foo changes should be inspected. I broke ipv6 once doing something similar to v6 addresses. > Going to be fun to merge with my 70 outstanding patches though :) That's a cheery definition of fun. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[SKBUFF]: Fix up csum_start when head room changes
Hi Dave:
[SKBUFF]: Fix up csum_start when head room changes
Thanks for noticing the bug where csum_start is not updated
when the head room changes.
This patch fixes that. It also moves the csum/ip_summed
copying into copy_skb_header so that skb_copy_expand gets
it too. I've checked its callers and no one should be upset
by this.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 35021eb..944189d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -472,6 +472,9 @@ static void copy_skb_header(struct sk_buff *new, const
struct sk_buff *old)
#ifdef CONFIG_INET
new->sp = secpath_get(old->sp);
#endif
+ new->csum_start = old->csum_start;
+ new->csum_offset = old->csum_offset;
+ new->ip_summed = old->ip_summed;
new->transport_header = old->transport_header;
new->network_header = old->network_header;
new->mac_header = old->mac_header;
@@ -545,8 +548,6 @@ struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t
gfp_mask)
skb_reserve(n, headerlen);
/* Set the tail pointer and length */
skb_put(n, skb->len);
- n->csum = skb->csum;
- n->ip_summed = skb->ip_summed;
if (skb_copy_bits(skb, -headerlen, n->head, headerlen + skb->len))
BUG();
@@ -589,8 +590,6 @@ struct sk_buff *pskb_copy(struct sk_buff *skb, gfp_t
gfp_mask)
skb_put(n, skb_headlen(skb));
/* Copy the bytes */
skb_copy_from_linear_data(skb, n->data, n->len);
- n->csum = skb->csum;
- n->ip_summed = skb->ip_summed;
n->truesize += skb->data_len;
n->data_len = skb->data_len;
@@ -686,6 +685,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int
ntail,
skb->transport_header += off;
skb->network_header += off;
skb->mac_header += off;
+ skb->csum_start += off;
skb->cloned = 0;
skb->hdr_len = 0;
skb->nohdr= 0;
@@ -734,9 +734,6 @@ struct sk_buff *skb_realloc_headroom(struct sk_buff *skb,
unsigned int headroom)
*
* You must pass %GFP_ATOMIC as the allocation priority if this function
* is called from an interrupt.
- *
- * BUG ALERT: ip_summed is not copied. Why does this work? Is it used
- * only by netfilter in the cases when checksum is recalculated? --ANK
*/
struct sk_buff *skb_copy_expand(const struct sk_buff *skb,
int newheadroom, int newtailroom,
@@ -749,7 +746,7 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb,
gfp_mask);
int oldheadroom = skb_headroom(skb);
int head_copy_len, head_copy_off;
- int off = 0;
+ int off;
if (!n)
return NULL;
@@ -773,12 +770,13 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb,
copy_skb_header(n, skb);
-#ifdef NET_SKBUFF_DATA_USES_OFFSET
off = newheadroom - oldheadroom;
-#endif
+ n->csum_start += off;
+#ifdef NET_SKBUFF_DATA_USES_OFFSET
n->transport_header += off;
n->network_header += off;
n->mac_header += off;
+#endif
return n;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.24 4/5]S2io: Check for CARD_DOWN before handling traffic
Jeff,
> > - Added check to return from the traffic handling function, if the
card
> status
> > is DOWN.
> >
> > Signed-off-by: Sivakumar Subramani
<[EMAIL PROTECTED]>
> > Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
> > Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
> > ---
> > diff -Nurp patch3/drivers/net/s2io.c patch4/drivers/net/s2io.c
> > --- patch3/drivers/net/s2io.c 2007-08-15 08:57:32.0
-0700
> > +++ patch4/drivers/net/s2io.c 2007-08-15 08:42:14.0
-0700
> > @@ -2927,6 +2927,11 @@ static int s2io_poll(struct net_device *
> > int i;
> >
> > atomic_inc(&nic->isr_cnt);
> > + if (unlikely(atomic_read(&nic->card_state) == CARD_DOWN)) {
> > + atomic_dec(&nic->isr_cnt);
> > + return IRQ_NONE;
> > + }
> > +
> > mac_control = &nic->mac_control;
> > config = &nic->config;
> >
>
> invalid return value, for this function
>
> Overall, this looks quite racy -- why does the card state differ from
> net_device state in the first place?
[Ram] Agreed, it is racy. Will use test_and_set_bit(), set_bit() and
clear_bit().
The card reset could be initiated due to an internal error detected in
one of the blocks in the chip, while interrupts are still occurring.
There is a net_device state (LINK_STATE_START) set at open and reset at
close but none for temporary disabled/enabled states. Did you want us to
use this enum along with the CARRIER states?
Ram
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals
2007/8/30, John W. Linville <[EMAIL PROTECTED]>: > On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote: > > 2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>: > > > > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by > > > most drivers and ath5k_hw_inivals.o mights aswell be something like > > > ath5k_init.o > > > If you check out the code you'll see i'm using the same convention > > inside them, ath5k_hw* files contain hw related functions > > (ath5k_hw_) while driver code has ath5k_. Also ath5k_init > > is misleading, file acually includes initial register settings for > > I have to agree w/ Christoph -- the extra "_hw" in the names is just > a bit unwieldy. > > John > > P.S. "ath5k_initvals.c" seems acceptable to me. ACK, i'll remove _hw ;-) -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zd1211rw regression, device does not enumerate
Oliver Neukum wrote: after bisection it boils down to this patch: [EMAIL PROTECTED]:/home/olli2/Trees/linux-2.6> git bisect bad 74553aedd46b3a2cae986f909cf2a3f99369decc is first bad commit commit 74553aedd46b3a2cae986f909cf2a3f99369decc Author: Daniel Drake <[EMAIL PROTECTED]> Date: Sun Jul 1 18:22:32 2007 +0100 [PATCH] zd1211rw: Defer firmware load until first ifup that plugging in my device I get an error: Aug 16 13:17:11 oenone kernel: zd1211rw 3-4.3:1.0: zd1211b chip 0ace:1215 v4810 high 00-02-72 AL2230_RF pa0 g--NS Aug 16 13:17:12 oenone ifup: Cannot enable interface eth2. Can you enable CONFIG_ZD1211RW_DEBUG and post new logs? Would also be nice to have a bug on the kernel bugzilla to track this. Thanks, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
borkage in 2.6.23-rc4-mm1
Am seeing random crap like this: Aug 31 20:57:46 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Aug 31 20:57:51 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Aug 31 20:57:56 sony dhclient: dhclient(4537) is already running - exiting. Aug 31 20:57:56 sony dhclient: exiting. Aug 31 20:58:05 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4 Aug 31 20:58:07 sony kernel: ipw2200: Firmware error detected. Restarting. Aug 31 20:58:09 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Aug 31 20:58:16 sony dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14 Aug 31 20:58:16 sony dhclient: DHCPOFFER from 192.168.2.1 Aug 31 20:58:16 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Aug 31 20:58:20 sony dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Aug 31 20:58:20 sony dhclient: DHCPACK from 192.168.2.1 Aug 31 20:58:20 sony NET[4946]: /sbin/dhclient-script : updated /etc/resolv.conf Aug 31 20:58:20 sony dhclient: bound to 192.168.2.5 -- renewal in 125513 seconds. Aug 31 20:59:45 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument Aug 31 20:59:51 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument Aug 31 20:59:52 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument Aug 31 21:01:31 sony kernel: ipw2200: Firmware error detected. Restarting. Aug 31 21:01:54 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument Aug 31 21:01:59 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument Aug 31 21:02:02 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument Aug 31 21:04:04 sony ntpd[2059]: sendto(192.36.143.234): Invalid argument Aug 31 21:04:05 sony kernel: ipw2200: Firmware error detected. Restarting. Aug 31 21:04:07 sony ntpd[2059]: sendto(193.225.14.163): Invalid argument Aug 31 21:04:12 sony ntpd[2059]: sendto(193.60.199.78): Invalid argument Aug 31 21:05:21 sony kernel: ipw2200: Firmware error detected. Restarting. when trying to use ssh on the current rc4-mm1 lineup. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv4_get_l4proto: Frag of proto 17
Meelis Roos wrote: Yesterdays git snapsot on a normal home PC spams dmesg with the following line: ipv4_get_l4proto: Frag of proto 17 In what situation does this happen? It happens some times every hour on the average. Seems to be some UDP traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP (some more UDP rules with counter 0 so not important). Additionally there is internal netowkr that sometimes has a laptop but usually not and the messages have appeared also when there is nothin in the internal network. Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening on UDP sockets (most of them on internal network). But I have no idea what application is causing the messages. I'm guessing that its ICMP errors containing UDP fragments. Could you add a WARN_ON(1) to ipv4_get_l4proto() in net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify this? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Net: ath5k, kconfig changes
2007/8/31, Nick Kossifidis <[EMAIL PROTECTED]>: > 2007/8/30, John W. Linville <[EMAIL PROTECTED]>: > > On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote: > > > 2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>: > > > > > > Also this whole patch seems rather pointless. It saves only > > > > very little and turns the driver into a complete ifdef maze. > > > > > Also most > > > people will use 5212 code only, 5211 cards are on some old laptops and > > > 5210, well i couldn't even find a 5210 for actual testing :P > > > > FWIW, I'd bet dollars to donuts that distros will enable them all > > together. > > > > Is saving code space the only reason to turn these off? How much > > space do you save? > > > > Is there some way you can isolate and/or limit the number of ifdef > > blocks further? If so, we might consider a version of this patch > > that depends on EMBEDDED or somesuch...? > > > > John > > O.K. as a first step i'll limit 5210 code only then, just an option > like "support older 5210 chipsets" which is going to be off by default > instead of 3 options. It's not just saving space, it's also saving > some runtime checks. It's not really a gain in performance though, > most checks are done during initialization and dfs setup, i just > thought it would be usefull to save as much cpu as possible. > Well after some thought i removed them all, there is no real gain from this in most cases (that ppl will use newer 5212 chips and combatibles). -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] skge: unbalanced parenthesis fix
Hello,
This patch fixes unbalanced parenthesis.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/net/skge.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.23-rc4-mm1-a/drivers/net/skge.h 2007-09-01 07:23:52.0
+0200
+++ linux-2.6.23-rc4-mm1-b/drivers/net/skge.h 2007-09-01 07:37:55.0
+0200
@@ -1351,7 +1351,7 @@ enum {
PHY_M_PC_EN_DET_PLUS= 3<<8, /* Energy Detect Plus (Mode 2) */
};
-#define PHY_M_PC_MDI_XMODE(x) u16)(x)<<5) & PHY_M_PC_MDIX_MSK)
+#define PHY_M_PC_MDI_XMODE(x) (((u16)(x)<<5) & PHY_M_PC_MDIX_MSK)
enum {
PHY_M_PC_MAN_MDI= 0, /* 00 = Manual MDI configuration */
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
