* Re: [PATCH] (resubmit) Use list_head-s in inetpeer.c
From: David Miller @ 2007-11-13 5:27 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <473862B1.206@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Mon, 12 Nov 2007 17:26:57 +0300
> The inetpeer.c tracks the LRU list of inet_perr-s, but makes
> it by hands. Use the list_head-s for this.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks Pavel.
^ permalink raw reply
* Re: [PATCH] - in.h - IP4_ADDR
From: David Miller @ 2007-11-13 5:28 UTC (permalink / raw)
To: joe; +Cc: netdev, fred.l.templin
In-Reply-To: <1194837570.9407.29.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Sun, 11 Nov 2007 19:19:30 -0800
> Add inline functions to in.h that make the IP4 address tests
> a bit easier to read and also add some type safety.
>
> gcc optimizes IP4_ADDR to a constant (O2 or Os)
>
> Signed-off-by: Joe Perches <joe@perches.com
I have no problems with this, but I'd like to add it along
with subsequent patches that use the new routines and
also I'd like to defer this to net-2.6.25 so please resubmit
this later.
Thanks!
^ permalink raw reply
* Re: DaveM collecting netdev patches this week
From: David Miller @ 2007-11-13 5:29 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel, akpm
In-Reply-To: <4737092F.3080600@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Sun, 11 Nov 2007 08:52:47 -0500
> David Miller has agreed to collect net driver bug fix patches in my
> absence, with Stephen and Francois (and others, hopefully) helping out
> with patch review.
I'll be integrating fixes directly into my usual net-2.6 tree at:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
so folks should submit fixes against that.
> David -- note that my 2.6.25 was opened a little while ago. If you feel
> motivated enough to collect non-bugfix patches, please make sure to
> apply them on top of netdev-2.6.git#upstream. There is already quite a
> collection of stuff for 2.6.25 queued...
I've cut a tree with this 2.6.25 network device driver stuff
that people can submit against at:
kernel.org:/pub/scm/linux/kernel/git/davem/netdev-2.6.git
Thanks.
^ permalink raw reply
* Re: [PATCH] Add support for the RDC R6040 Fast Ethernet controller
From: David Miller @ 2007-11-13 5:31 UTC (permalink / raw)
To: florian.fainelli; +Cc: netdev, shemminger, jeff
In-Reply-To: <200711122358.51432.florian.fainelli@telecomint.eu>
From: Florian Fainelli <florian.fainelli@telecomint.eu>
Date: Mon, 12 Nov 2007 23:58:48 +0100
> This patch adds support for the RDC R6040 MAC we can find in the RDC R-321x System-on-chips.
>
> Signed-off-by: Sten Wang <sten.wang@rdc.com.tw>
> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
> Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
I've added this to my netdev-2.6 tree, thanks!
^ permalink raw reply
* Re: [PATCH] - in.h - IP4_ADDR
From: Joe Perches @ 2007-11-13 5:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fred.l.templin
In-Reply-To: <20071112.212814.130544552.davem@davemloft.net>
On Mon, 2007-11-12 at 21:28 -0800, David Miller wrote:
> I have no problems with this, but I'd like to add it along
> with subsequent patches that use the new routines and
> also I'd like to defer this to net-2.6.25 so please resubmit
> this later.
I've since changed the functions in my tree to:
static inline bool is_ip4_foo(__be32 addr)
and added
# define FOO(x) is_ip4_foo(x)
which I think makes more sense and allows macro
removal when all current uses are converted.
When you open net-2.6.25, I'll resubmit it.
^ permalink raw reply
* [BUG] New Kernel Bugs
From: Natalie Protasevich @ 2007-11-13 6:42 UTC (permalink / raw)
To: linux-kernel, akpm, netdev, alsa-devel, linux-ide, linux-pcmcia,
linux-input@
This is the listing of the open bugs that are relatively new, around
2.6.22 and up. They are vaguely classified by specific area.
(not a full list, there are more :)
The good part is that reporters of the bugs below are still around and
haven't dissipated, or disposed of their hardware, so it is a good
time to get the bugs.
Those bugzillas that have been started as regressions on Rafael's list
are not mentioned here so far, since they are being tracked as new
regressions already.
It would be appreciated if the corresponding maintenance team could take a
look, close off any which are fixed and see if they can fix any which aren't.
NOTE: when replying to this email, please add the bug number to the Subject in
the form [Bug 1234] so that bugzilla will capture the discussion.
Thanks.
ACPI====================================================================
System does not load without acpi=off ide=nodma noapic
http://bugzilla.kernel.org/show_bug.cgi?id=9358
Kernel: 2.6.23.1
ACPI Error attaching device data
http://bugzilla.kernel.org/show_bug.cgi?id=9354
Kernel: 2.6.24-rc2
/proc/acpi/battery displays Incorrect voltages
http://bugzilla.kernel.org/show_bug.cgi?id=9341
Kernel: 2.6.23.1
PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object
http://bugzilla.kernel.org/show_bug.cgi?id=9320
Kernel: 2.6.24-rc2
(Tejun: calling _GTF without calling _STM first. _GTM doesn't have any
prerequisite (it can't). Can someone familiar with ACPI tell me why the method
is failing? At any rate, libata should work fine regardless of ACPI failures.
Maybe it's time to start blacklist to skip ATA-ACPI for some boards to avoid
those annoying messages during boot)
ACPI Battery Info in /sys but not /proc/acpi
http://bugzilla.kernel.org/show_bug.cgi?id=9183
Kernel: 2.6.23-rc8-mm2
When using ACPI on a Compaq Presario V6221EU the laptop goes into
deadlock after a random amount of time
http://bugzilla.kernel.org/show_bug.cgi?id=9118
Kernel: 2.6.23-rc6
ACPI video driver should validate brightness level before setting it via _BCM
http://bugzilla.kernel.org/show_bug.cgi?id=9277
Kernel: 2.6.23
VIDEO/DVB
dvb driver reboot system
http://bugzilla.kernel.org/show_bug.cgi?id=9357
Kernel: 2.6.21.5
PLATFORM===============================================================
xipImage is built so that uBoot cant run it (ARM)
http://bugzilla.kernel.org/show_bug.cgi?id=9356
Kernel: 2.6.21
Samsung R20 - ACPI: PCI Root Bridge [PCI0] (0000:00)
http://bugzilla.kernel.org/show_bug.cgi?id=9339
Kernel: 2.6.24
(boot is very long
..MP-BIOS bug: 8254 timer not connected to IO-APIC
then the boot stop at :
ACPI: PCI Root Bridge [PCI0] (0000:00)
(during 3 minutes, and boot continue)
system_64.h: switch_to inline asm should be more robbust wrt optimizations
http://bugzilla.kernel.org/show_bug.cgi?id=9302
Kernel: 2.6.24-rc1
with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't
boot (ARM, Timer)
http://bugzilla.kernel.org/show_bug.cgi?id=9229
Kernel: 2.6.23
NETWORKING===========================================================
RTNLGRP_ND_USEROPT does not report ifindex (IPv6)
http://bugzilla.kernel.org/show_bug.cgi?id=9349
Kernel: 2.6.24+
a kernel error happend in the func: __skb_dequeue when using in
pfifo_fast_dequeue
http://bugzilla.kernel.org/show_bug.cgi?id=9342
Kernel: 2.6.11.1 - reporter asked to try recent kernel
e100 does not work after boot
http://bugzilla.kernel.org/show_bug.cgi?id=9336
Kernel: 2.6.23.1
2.6.23.1-smp kernel panic (network-related)
http://bugzilla.kernel.org/show_bug.cgi?id=9318
Kernel: 2.6.23.1
Infiniband panic
sundance -> 4port D-Link System Inc DFE-580TX -> Log errors
http://bugzilla.kernel.org/show_bug.cgi?id=9311
Kernel: 2.6.22.9
via-rhine driver stalls with: PHY status 786d, resetting...
http://bugzilla.kernel.org/show_bug.cgi?id=9300
Kernel: 2.6.23+
Weird network problems with 2.6.23-rc2
http://bugzilla.kernel.org/show_bug.cgi?id=9080
http://lkml.org/lkml/2007/8/11/40 - description
rt2500pci: low TCP throughput (wireless)
http://bugzilla.kernel.org/show_bug.cgi?id=9273
Kernel: 2.6.24-rc1
This is a regression
Unable to build wifi network between zd1201 and b43
http://bugzilla.kernel.org/show_bug.cgi?id=9237
Kernel: 2.6.24-rc1
Crash after module unload in b43 (wireless)
http://bugzilla.kernel.org/show_bug.cgi?id=9233
Kernel: 2.6.24-rc1
(net typhoon) "no descs for cmd, had (needed) 0 (1) cmd, 31 (7) resp"
http://bugzilla.kernel.org/show_bug.cgi?id=9225
Kernel: 2.6.23.1
IDE/SATA=========================================================
pata_pdc202xx_old excessive ATA bus errors
http://bugzilla.kernel.org/show_bug.cgi?id=9337
2.6.24-rc2
Drive seagate ST380011AS needs to be blacklisted
http://bugzilla.kernel.org/show_bug.cgi?id=9309
Kernel: 2.6.22.X
DVD-RAM umount and disk free bug
http://bugzilla.kernel.org/show_bug.cgi?id=9265
Kernel: 2.6.15 (asked to try current kernel)
FILE SYSTEMS=======================================================
ext4: delalloc space accounting problem drops data
http://bugzilla.kernel.org/show_bug.cgi?id=9329
Kernel: 2.6.24-rc1
POSIX Access Control Lists cause bogus file system check errors
http://bugzilla.kernel.org/show_bug.cgi?id=9241
Kernel: 2.6.23.1
MEMORY MANAGEMENT================================================
My system hangs when it has no more free memory to allocate via malloc()
http://bugzilla.kernel.org/show_bug.cgi?id=9316
Kernel: 2.6.23
User program, "My system hangs when it has no more free memory to
allocate via malloc()"
BUG: unable to handle kernel paging request at virtual address
26121228/kswapd0[231] exited with preempt_count 1
http://bugzilla.kernel.org/show_bug.cgi?id=9305
EIP is at free_block+0x6d/0xe4
Kernel: 2.6.22.6
POWER MANAGEMENT==================================================
IBM X41 looses time after Suspend2Disk
http://bugzilla.kernel.org/show_bug.cgi?id=9314
Kernel: 2.6.23
Suspend to RAM resume hangs on a tickless (NO_HZ) kernel
http://bugzilla.kernel.org/show_bug.cgi?id=9275
Kernel: 2.6.23
This is HP notebook nc6320 T2400 945GM
VIDEO DRIVERS========================================================
No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
http://bugzilla.kernel.org/show_bug.cgi?id=9310
Kernel: 2.6.24-rc1
This is a regression
PARALLEL PORT========================================================
LPC IT8705 POST port making noise on parallel port
http://bugzilla.kernel.org/show_bug.cgi?id=9306
Kernel: 2.6.16+
I/O STORAGE===========================================================
kernel bug from pktcdvd
http://bugzilla.kernel.org/show_bug.cgi?id=9294
Kernel: 2.6.23
After pci-e video card was installed, pci add-on usb card & firewire card fail
http://bugzilla.kernel.org/show_bug.cgi?id=9223
Kernel: 2.6.20 (testing of latest kernel requested)
SCSI==================================================================
qla2xxx: driver initialization does not complete when booting with
Port connected
http://bugzilla.kernel.org/show_bug.cgi?id=9267
Kernel: 2.6.23.1
SOUND ALSA============================================================
Unable to load snd-hda-intel module: Unknown symbol in module, or
unknown parameter
http://bugzilla.kernel.org/show_bug.cgi?id=9242
Kernel: 2.6.24-rc1
usbaudio microphone: regular sound distortion on several Logitech Webcams
http://bugzilla.kernel.org/show_bug.cgi?id=9230
Kernel: 2.6.22.9
HID====================================================================
Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc
http://bugzilla.kernel.org/show_bug.cgi?id=9216
Kernel: 2.6.23.1
Looks like this is a regression
^ permalink raw reply
* [PATCH] Fix warning for token-ring from sysctl checker
From: Olof Johansson @ 2007-11-13 7:23 UTC (permalink / raw)
To: akpm; +Cc: netdev, linux-kernel, Eric W. Biederman
As seen when booting ppc64_defconfig:
sysctl table check failed: /net/token-ring .3.14 procname does not match binary path procname
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 5a2f2b2..4abc6d2 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_ROSE, "rose", trans_net_rose_table },
{ NET_IPV6, "ipv6", trans_net_ipv6_table },
{ NET_X25, "x25", trans_net_x25_table },
- { NET_TR, "tr", trans_net_tr_table },
+ { NET_TR, "token-ring", trans_net_tr_table },
{ NET_DECNET, "decnet", trans_net_decnet_table },
/* NET_ECONET not used */
{ NET_SCTP, "sctp", trans_net_sctp_table },
^ permalink raw reply related
* [PATCH] IPV4: add raw drops counter
From: Wang Chen @ 2007-11-13 9:57 UTC (permalink / raw)
To: netdev
Add raw drops counter for IPv4 in /proc/net/raw .
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
---
include/net/sock.h | 2 ++
net/core/sock.c | 1 +
net/ipv4/raw.c | 16 +++++++++-------
3 files changed, 12 insertions(+), 7 deletions(-)
diff -Nurp linux-2.6.24-rc2.org/include/net/sock.h linux-2.6.24-rc2/include/net/sock.h
--- linux-2.6.24-rc2.org/include/net/sock.h 2007-11-09 16:37:08.000000000 +0800
+++ linux-2.6.24-rc2/include/net/sock.h 2007-11-13 15:19:20.000000000 +0800
@@ -156,6 +156,7 @@ struct sock_common {
* @sk_prot_creator: sk_prot of original sock creator (see ipv6_setsockopt, IPV6_ADDRFORM for instance)
* @sk_err: last error
* @sk_err_soft: errors that don't cause failure but are the cause of a persistent failure not just 'timed out'
+ * @sk_drops: raw drops counter
* @sk_ack_backlog: current listen backlog
* @sk_max_ack_backlog: listen backlog set in listen()
* @sk_priority: %SO_PRIORITY setting
@@ -239,6 +240,7 @@ struct sock {
rwlock_t sk_callback_lock;
int sk_err,
sk_err_soft;
+ atomic_t sk_drops;
unsigned short sk_ack_backlog;
unsigned short sk_max_ack_backlog;
__u32 sk_priority;
diff -Nurp linux-2.6.24-rc2.org/net/core/sock.c linux-2.6.24-rc2/net/core/sock.c
--- linux-2.6.24-rc2.org/net/core/sock.c 2007-11-09 16:37:40.000000000 +0800
+++ linux-2.6.24-rc2/net/core/sock.c 2007-11-13 15:20:53.000000000 +0800
@@ -1611,6 +1611,7 @@ void sock_init_data(struct socket *sock,
sk->sk_stamp = ktime_set(-1L, -1L);
atomic_set(&sk->sk_refcnt, 1);
+ atomic_set(&sk->sk_drops, 0);
}
void fastcall lock_sock_nested(struct sock *sk, int subclass)
diff -Nurp linux-2.6.24-rc2.org/net/ipv4/raw.c linux-2.6.24-rc2/net/ipv4/raw.c
--- linux-2.6.24-rc2.org/net/ipv4/raw.c 2007-11-09 16:37:56.000000000 +0800
+++ linux-2.6.24-rc2/net/ipv4/raw.c 2007-11-13 15:48:17.000000000 +0800
@@ -241,7 +241,7 @@ static int raw_rcv_skb(struct sock * sk,
/* Charge it to the socket. */
if (sock_queue_rcv_skb(sk, skb) < 0) {
- /* FIXME: increment a raw drops counter here */
+ atomic_inc(&sk->sk_drops);
kfree_skb(skb);
return NET_RX_DROP;
}
@@ -866,28 +866,30 @@ static __inline__ char *get_raw_sock(str
srcp = inet->num;
sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X"
- " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p",
+ " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d",
i, src, srcp, dest, destp, sp->sk_state,
atomic_read(&sp->sk_wmem_alloc),
atomic_read(&sp->sk_rmem_alloc),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
- atomic_read(&sp->sk_refcnt), sp);
+ atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
return tmpbuf;
}
+#define TMPSZ 128
+
static int raw_seq_show(struct seq_file *seq, void *v)
{
- char tmpbuf[129];
+ char tmpbuf[TMPSZ+1];
if (v == SEQ_START_TOKEN)
- seq_printf(seq, "%-127s\n",
+ seq_printf(seq, "%-*s\n", TMPSZ-1,
" sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode");
+ "inode drops");
else {
struct raw_iter_state *state = raw_seq_private(seq);
- seq_printf(seq, "%-127s\n",
+ seq_printf(seq, "%-*s\n", TMPSZ-1,
get_raw_sock(v, tmpbuf, state->bucket));
}
return 0;
^ permalink raw reply
* Re: Problem with frame time stamping
From: Antoine Zen-Ruffinen @ 2007-11-13 10:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <20071112174759.c2777ea2.dada1@cosmosbay.com>
What does it bring me to have a nanosecond precision if it is not
related to the actual arrival of frame time ? As it seem I can feel
skb->tstamp with whatever I want, I always become something else using
ioctl(). (I'm using kernel 2.6.23).
2007/11/12, Eric Dumazet <dada1@cosmosbay.com>:
> On Mon, 12 Nov 2007 16:42:34 +0100
> "Antoine Zen-Ruffinen" <antoine.zen@gmail.com> wrote:
>
> > Dear all,
> >
> > I'm writing a network analyzer software using Linux and I need a VERY
> > precise frame time stamping. Therefor I am planing to add my own time
> > stamping algorithm on a modified network driver. For test purpose I
> > did so :
> >
> > skb->tstamp.tv64 = 0x00010002;
> > netif_rx(skb);
> >
> > On the user side, I ask for the timestamp that way :
> >
> > ...
> > sock = socket(AF_PACKET, SOCK_RAW, type);
> > ...
> > //bind this socket with the interface using my modified driver.
> > ...
> > recvByteCount = recv(sock, buffer, 1514, 0);
> > ioctl(sock, SIOCGSTAMP, &timeStamp);
> >
> > I was surprised to see that the var timeStamp was still holding a
> > count of second since year 1970.
> >
> > Investigating a bit into the kernel code, I found that ioctl(sock,
> > SIOCGSTAMP, ...) was giving just the current kernel time using
> > ktime_get_real().
> >
> > Are my investigation wrong ?
> > Is that a bug in kernel code ?
> > Is there an other way to access skb.tstamp from user side ?
> >
> > Thank's to any one that can help me !
>
> If your kernel is recent enough, you can already get nanosecond precision from skb tstamp, using SIOCGSTAMPNS ioctl or SO_TIMESTAMPNS / SCM_TIMESTAMPNS
>
> (changes where done in March/April this year)
>
> http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=b7aa0bf70c4afb9e38be25f5c0922498d0f8684c
>
> http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=ae40eb1ef30ab4120bd3c8b7e3da99ee53d27a23
>
> http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=92f37fd2ee805aa77925c1e64fd56088b46094fc
>
>
> No need to modify a network driver :)
>
>
>
^ permalink raw reply
* [PATCH] Add the phy_device_release device method.
From: Thierry Reding @ 2007-11-13 10:21 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]
In cases where more than a single PHY is found on the MDIO bus, the kernel
will print a warning that this method is missing for each PHY device that
has not been attached to a networking device.
---
drivers/net/phy/mdio_bus.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index fc2f0e6..cb7fb47 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -36,6 +36,23 @@
#include <asm/uaccess.h>
/**
+ * phy_device_release - free a phy_device structure when all users of it are
+ * finished.
+ *
+ * @dev: device that's been removed
+ *
+ * Will be called only by the device core when all users of this phy_device
+ * are done.
+ */
+static void phy_device_release(struct device *dev)
+{
+ struct phy_device *phy;
+
+ phy = to_phy_device(dev);
+ kfree(phy);
+}
+
+/**
* mdiobus_register - bring up all the PHYs on a given bus and attach them to bus
* @bus: target mii_bus
*
@@ -83,6 +100,7 @@ int mdiobus_register(struct mii_bus *bus)
if (phydev) {
phydev->irq = bus->irq[i];
+ phydev->dev.release = phy_device_release;
phydev->dev.parent = bus->dev;
phydev->dev.bus = &mdio_bus_type;
snprintf(phydev->dev.bus_id, BUS_ID_SIZE, PHY_ID_FMT, bus->id, i);
@@ -112,7 +130,6 @@ void mdiobus_unregister(struct mii_bus *bus)
for (i = 0; i < PHY_MAX_ADDR; i++) {
if (bus->phy_map[i]) {
device_unregister(&bus->phy_map[i]->dev);
- kfree(bus->phy_map[i]);
}
}
}
--
1.5.3.5
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Patrick McHardy @ 2007-11-13 10:21 UTC (permalink / raw)
To: Joonwoo Park
Cc: David Miller, w, cfriesen, auke-jan.h.kok, netdev,
djohnson+linux-kernel, linux-kernel, e1000-devel
In-Reply-To: <b25c3fa70711121721o32bcab0fldf64ff0434a44a3c@mail.gmail.com>
Joonwoo Park wrote:
> 2007/11/13, David Miller <davem@davemloft.net>:
>
>> From: Willy Tarreau <w@1wt.eu>
>> Date: Tue, 13 Nov 2007 00:32:57 +0100
>>
>>
>>> At least, being able to disable the feature at module load time
>>> would be acceptable. Many people who often need to sniff on decent
>>> machines would always keep it disabled.
>>>
>> I'm willing to accept the feature, in whatever form, as long
>> as the performance issue is dealt with properly.
>>
>
> I agree with disabling the hw acceleration feature by manually would
> be a non-negative solution.
> IMO implementation in the ethtool seems better than module param.
> As like Auke mentioned.
> If you guys confirm it, I'll try it.
>
I still think promiscous mode should disable all filters (which would
also provide a consistent view between accerlated and non-accerlated
devices), but an ethtool option is better than nothing :)
^ permalink raw reply
* Re: Problem with frame time stamping
From: Eric Dumazet @ 2007-11-13 10:27 UTC (permalink / raw)
To: Antoine Zen-Ruffinen; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <2cbbd8de0711130207t82f2f46h9ee1b876a61bad6a@mail.gmail.com>
Antoine Zen-Ruffinen a écrit :
> What does it bring me to have a nanosecond precision if it is not
> related to the actual arrival of frame time ? As it seem I can feel
> skb->tstamp with whatever I want, I always become something else using
> ioctl(). (I'm using kernel 2.6.23).
>
>
I guess you misunderstood kernel source, because it is related to
arrival time, more exactly when it was processed by network stack.
(Beware modern NICS can delay the rx interrupt by some us (ethtool -c
eth0), so that an interrupt can feed more than one packet to the OS)
Check net/core/dev.c function netif_rx()
{
...
if (!skb->tstamp.tv64)
net_timestamp(skb);
}
So as soon your system as at least one socket 'asking for tsamps',
netstamp_needed is not null, and net_timestamp() will call __net_timestamp()
wich does :
skb->tstamp = ktime_get_real();
So you should not 'feed' tstamp.tv64 and let it being 0, so that
netif_rx() can do its job.
^ permalink raw reply
* [PATCH] IPVS: Fix sysctl warnings about missing strategy
From: Christian Borntraeger @ 2007-11-13 10:29 UTC (permalink / raw)
To: netdev; +Cc: Eric W. Biederman, Wensong Zhang, Simon Horman, Julian Anastasov
Running the latest git code I get the following messages during boot:
sysctl table check failed: /net/ipv4/vs/drop_entry .3.5.21.4 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/drop_packet .3.5.21.5 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/secure_tcp .3.5.21.6 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/sync_threshold .3.5.21.24 Missing strategy
I removed the binary sysctl handler for those messages and also removed
the definitions in ip_vs.h. The alternative would be to implement a
proper strategy handler, but syscall sysctl is deprecated.
There are other sysctl definitions that are commented out or work with
the default sysctl_data strategy. I did not touch these.
Eric, IPVS team, are you ok with that change?
CC: Eric W. Biederman <ebiederm@xmission.com>
CC: Wensong Zhang <wensong@linux-vs.org>
CC: Simon Horman <horms@verge.net.au>
CC: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
include/net/ip_vs.h | 4 ----
kernel/sysctl_check.c | 4 ----
net/ipv4/ipvs/ip_vs_ctl.c | 4 ----
3 files changed, 12 deletions(-)
Index: linux-2.6/include/net/ip_vs.h
===================================================================
--- linux-2.6.orig/include/net/ip_vs.h
+++ linux-2.6/include/net/ip_vs.h
@@ -336,9 +336,6 @@ enum {
NET_IPV4_VS_DEBUG_LEVEL=1,
NET_IPV4_VS_AMEMTHRESH=2,
NET_IPV4_VS_AMDROPRATE=3,
- NET_IPV4_VS_DROP_ENTRY=4,
- NET_IPV4_VS_DROP_PACKET=5,
- NET_IPV4_VS_SECURE_TCP=6,
NET_IPV4_VS_TO_ES=7,
NET_IPV4_VS_TO_SS=8,
NET_IPV4_VS_TO_SR=9,
@@ -355,7 +352,6 @@ enum {
NET_IPV4_VS_LBLCR_EXPIRE=20,
NET_IPV4_VS_CACHE_BYPASS=22,
NET_IPV4_VS_EXPIRE_NODEST_CONN=23,
- NET_IPV4_VS_SYNC_THRESHOLD=24,
NET_IPV4_VS_NAT_ICMP_SEND=25,
NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE=26,
NET_IPV4_VS_LAST
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
===================================================================
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
@@ -1451,7 +1451,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_dointvec,
},
{
- .ctl_name = NET_IPV4_VS_DROP_ENTRY,
.procname = "drop_entry",
.data = &sysctl_ip_vs_drop_entry,
.maxlen = sizeof(int),
@@ -1459,7 +1458,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_do_defense_mode,
},
{
- .ctl_name = NET_IPV4_VS_DROP_PACKET,
.procname = "drop_packet",
.data = &sysctl_ip_vs_drop_packet,
.maxlen = sizeof(int),
@@ -1467,7 +1465,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_do_defense_mode,
},
{
- .ctl_name = NET_IPV4_VS_SECURE_TCP,
.procname = "secure_tcp",
.data = &sysctl_ip_vs_secure_tcp,
.maxlen = sizeof(int),
@@ -1597,7 +1594,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_dointvec,
},
{
- .ctl_name = NET_IPV4_VS_SYNC_THRESHOLD,
.procname = "sync_threshold",
.data = &sysctl_ip_vs_sync_threshold,
.maxlen = sizeof(sysctl_ip_vs_sync_threshold),
Index: linux-2.6/kernel/sysctl_check.c
===================================================================
--- linux-2.6.orig/kernel/sysctl_check.c
+++ linux-2.6/kernel/sysctl_check.c
@@ -242,9 +242,6 @@ static struct trans_ctl_table trans_net_
{ NET_IPV4_VS_AMEMTHRESH, "amemthresh" },
{ NET_IPV4_VS_DEBUG_LEVEL, "debug_level" },
{ NET_IPV4_VS_AMDROPRATE, "am_droprate" },
- { NET_IPV4_VS_DROP_ENTRY, "drop_entry" },
- { NET_IPV4_VS_DROP_PACKET, "drop_packet" },
- { NET_IPV4_VS_SECURE_TCP, "secure_tcp" },
{ NET_IPV4_VS_TO_ES, "timeout_established" },
{ NET_IPV4_VS_TO_SS, "timeout_synsent" },
{ NET_IPV4_VS_TO_SR, "timeout_synrecv" },
@@ -260,7 +257,6 @@ static struct trans_ctl_table trans_net_
{ NET_IPV4_VS_CACHE_BYPASS, "cache_bypass" },
{ NET_IPV4_VS_EXPIRE_NODEST_CONN, "expire_nodest_conn" },
{ NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE, "expire_quiescent_template" },
- { NET_IPV4_VS_SYNC_THRESHOLD, "sync_threshold" },
{ NET_IPV4_VS_NAT_ICMP_SEND, "nat_icmp_send" },
{ NET_IPV4_VS_LBLC_EXPIRE, "lblc_expiration" },
{ NET_IPV4_VS_LBLCR_EXPIRE, "lblcr_expiration" },
^ permalink raw reply
* Re: Problem with frame time stamping
From: Eric Dumazet @ 2007-11-13 10:36 UTC (permalink / raw)
To: Antoine Zen-Ruffinen; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <2cbbd8de0711130207t82f2f46h9ee1b876a61bad6a@mail.gmail.com>
Antoine Zen-Ruffinen a écrit :
> What does it bring me to have a nanosecond precision if it is not
> related to the actual arrival of frame time ? As it seem I can feel
> skb->tstamp with whatever I want, I always become something else using
> ioctl(). (I'm using kernel 2.6.23).
>
> 2007/11/12, Eric Dumazet <dada1@cosmosbay.com>:
>
>> On Mon, 12 Nov 2007 16:42:34 +0100
>> "Antoine Zen-Ruffinen" <antoine.zen@gmail.com> wrote:
>>
>>
>>> Dear all,
>>>
>>> I'm writing a network analyzer software using Linux and I need a VERY
>>> precise frame time stamping. Therefor I am planing to add my own time
>>> stamping algorithm on a modified network driver. For test purpose I
>>> did so :
>>>
>>> skb->tstamp.tv64 = 0x00010002;
>>> netif_rx(skb);
>>>
>>> On the user side, I ask for the timestamp that way :
>>>
>>> ...
>>> sock = socket(AF_PACKET, SOCK_RAW, type);
>>> ...
>>> //bind this socket with the interface using my modified driver.
>>> ...
>>> recvByteCount = recv(sock, buffer, 1514, 0);
>>> ioctl(sock, SIOCGSTAMP, &timeStamp);
>>>
>>> I was surprised to see that the var timeStamp was still holding a
>>> count of second since year 1970.
>>>
But then, maybe your problem comes from your code : timeStamp should be
declared as "struct timeval" of course, to get both tv_sec and tv_usec.
struct timeval tv;
ioctl(sock, SIOCSTAMP, &tv);
printf("packet arrived at %ld.%06ld\n", (long)tv.tv_sec, (long)tv.tv_usec);
If you *want* nanosecond resolution instead of microsecond, use :
struct timespec ts;
ioctl(sock, SIOCSTAMPNS, &ts);
printf("packet arrived at %ld.%09ld\n", (long)ts.tv_sec, (long)ts.tv_nsec);
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem with frame time stamping
From: Antoine Zen-Ruffinen @ 2007-11-13 10:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <47397C0C.4060106@cosmosbay.com>
This is exactly my problem : The driver of the network card I am using
(see rt2x00.serialmonkey.com) do the minimum in the hardware interrupt
(not filling skb->tstamp). Then netif_rx() is called later using a
tasklet (also not filling skb->tstamp). As it seem to me (maybe I am
wrong, if so please tell), the elapse time between the actual frame
arrival and the time where netif_rx() do net_timestamp(skb) is not
predicable !?
Else, I would like to thank you to spend time helping me.
2007/11/13, Eric Dumazet <dada1@cosmosbay.com>:
> Antoine Zen-Ruffinen a écrit :
> > What does it bring me to have a nanosecond precision if it is not
> > related to the actual arrival of frame time ? As it seem I can feel
> > skb->tstamp with whatever I want, I always become something else using
> > ioctl(). (I'm using kernel 2.6.23).
> >
> >
> I guess you misunderstood kernel source, because it is related to
> arrival time, more exactly when it was processed by network stack.
> (Beware modern NICS can delay the rx interrupt by some us (ethtool -c
> eth0), so that an interrupt can feed more than one packet to the OS)
>
> Check net/core/dev.c function netif_rx()
>
> {
> ...
> if (!skb->tstamp.tv64)
> net_timestamp(skb);
>
> }
>
> So as soon your system as at least one socket 'asking for tsamps',
> netstamp_needed is not null, and net_timestamp() will call __net_timestamp()
> wich does :
>
> skb->tstamp = ktime_get_real();
>
> So you should not 'feed' tstamp.tv64 and let it being 0, so that
> netif_rx() can do its job.
>
>
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem with frame time stamping
From: Antoine Zen-Ruffinen @ 2007-11-13 10:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <2cbbd8de0711130239j67127e1cxf312033aee1ddd5a@mail.gmail.com>
no worries ont that side, In my code timeStamp is a "struct timeval".
2007/11/13, Antoine Zen-Ruffinen <antoine.zen@gmail.com>:
> This is exactly my problem : The driver of the network card I am using
> (see rt2x00.serialmonkey.com) do the minimum in the hardware interrupt
> (not filling skb->tstamp). Then netif_rx() is called later using a
> tasklet (also not filling skb->tstamp). As it seem to me (maybe I am
> wrong, if so please tell), the elapse time between the actual frame
> arrival and the time where netif_rx() do net_timestamp(skb) is not
> predicable !?
>
> Else, I would like to thank you to spend time helping me.
>
>
>
> 2007/11/13, Eric Dumazet <dada1@cosmosbay.com>:
> > Antoine Zen-Ruffinen a écrit :
> > > What does it bring me to have a nanosecond precision if it is not
> > > related to the actual arrival of frame time ? As it seem I can feel
> > > skb->tstamp with whatever I want, I always become something else using
> > > ioctl(). (I'm using kernel 2.6.23).
> > >
> > >
> > I guess you misunderstood kernel source, because it is related to
> > arrival time, more exactly when it was processed by network stack.
> > (Beware modern NICS can delay the rx interrupt by some us (ethtool -c
> > eth0), so that an interrupt can feed more than one packet to the OS)
> >
> > Check net/core/dev.c function netif_rx()
> >
> > {
> > ...
> > if (!skb->tstamp.tv64)
> > net_timestamp(skb);
> >
> > }
> >
> > So as soon your system as at least one socket 'asking for tsamps',
> > netstamp_needed is not null, and net_timestamp() will call __net_timestamp()
> > wich does :
> >
> > skb->tstamp = ktime_get_real();
> >
> > So you should not 'feed' tstamp.tv64 and let it being 0, so that
> > netif_rx() can do its job.
> >
> >
> >
> >
> >
> >
>
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] IPVS: Fix sysctl warnings about missing strategy
From: David Miller @ 2007-11-13 10:45 UTC (permalink / raw)
To: borntraeger; +Cc: netdev, ebiederm, wensong, horms, ja
In-Reply-To: <200711131129.58868.borntraeger@de.ibm.com>
From: Christian Borntraeger <borntraeger@de.ibm.com>
Date: Tue, 13 Nov 2007 11:29:58 +0100
> Running the latest git code I get the following messages during boot:
> sysctl table check failed: /net/ipv4/vs/drop_entry .3.5.21.4 Missing strategy
> [...]
> sysctl table check failed: /net/ipv4/vs/drop_packet .3.5.21.5 Missing strategy
> [...]
> sysctl table check failed: /net/ipv4/vs/secure_tcp .3.5.21.6 Missing strategy
> [...]
> sysctl table check failed: /net/ipv4/vs/sync_threshold .3.5.21.24 Missing strategy
>
> I removed the binary sysctl handler for those messages and also removed
> the definitions in ip_vs.h. The alternative would be to implement a
> proper strategy handler, but syscall sysctl is deprecated.
>
> There are other sysctl definitions that are commented out or work with
> the default sysctl_data strategy. I did not touch these.
>
> Eric, IPVS team, are you ok with that change?
>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> CC: Wensong Zhang <wensong@linux-vs.org>
> CC: Simon Horman <horms@verge.net.au>
> CC: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Simon planned to make a similar change to dice all of this
stuff up. He is travelling currently, and I think it's
reasonable to give him some time to get to it.
^ permalink raw reply
* Re: Problem with frame time stamping
From: Eric Dumazet @ 2007-11-13 10:55 UTC (permalink / raw)
To: Antoine Zen-Ruffinen; +Cc: netdev, linux-net, netfilter-devel, patrik.arlos
In-Reply-To: <2cbbd8de0711130239j67127e1cxf312033aee1ddd5a@mail.gmail.com>
Antoine Zen-Ruffinen a écrit :
> This is exactly my problem : The driver of the network card I am using
> (see rt2x00.serialmonkey.com) do the minimum in the hardware interrupt
> (not filling skb->tstamp). Then netif_rx() is called later using a
> tasklet (also not filling skb->tstamp). As it seem to me (maybe I am
> wrong, if so please tell), the elapse time between the actual frame
> arrival and the time where netif_rx() do net_timestamp(skb) is not
> predicable !?
>
> Else, I would like to thank you to spend time helping me.
>
>
>
A tasklet could process the skb much later than corresponding IRQ,
depending on various things
(other tasks/softirqs on system with higher priorities). So yes, it is
not predictable at all.
Usually it doesnt matter, but if your business depends on precise tstamps,
then just do skb->tstamp = ktime_get_real(); in IRQ handler (but it will
slow it a bit,
depending on how fast is ktime_get_real() on the target machine)
netif_rx() wont overwrite it.
skb = dev_alloc_skb(desc.size + NET_IP_ALIGN);
if (!skb)
return;
skb->tstamp = ktime_get_real(); /* do it before other copies */
skb_reserve(skb, NET_IP_ALIGN);
skb_put(skb, desc.size);
memcpy(skb->data, entry->data_addr, desc.size);
...
^ permalink raw reply
* Re: [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration
From: Daniel Lezcano @ 2007-11-13 10:55 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Denis V. Lunev, davem, netdev, xemul, containers, yoshfuji,
Benjamin Thery
In-Reply-To: <m16407450i.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Daniel Lezcano <dlezcano@fr.ibm.com> writes:
>
>> Eric W. Biederman wrote:
>>> "Denis V. Lunev" <den@sw.ru> writes:
>>>
>>>>> Index: linux-2.6-netns/net/ipv6/addrconf.c
>>>>> ===================================================================
>>>>> --- linux-2.6-netns.orig/net/ipv6/addrconf.c
>>>>> +++ linux-2.6-netns/net/ipv6/addrconf.c
>>>>> @@ -2272,7 +2272,8 @@ static int addrconf_notify(struct notifi
>>>>> switch(event) {
>>>>> case NETDEV_REGISTER:
>>>>> - if (!idev && dev->mtu >= IPV6_MIN_MTU) {
>>>>> + if (!(dev->flags & IFF_LOOPBACK) &&
>>>>> + !idev && dev->mtu >= IPV6_MIN_MTU) {
>>> It is idev being true here for the loopback device that would
>>> prevent things not missing the REGISTER event.
>>>
>>> Hmm. But we do call ipv6_add_dev on loopback and now the loopback
>>> device is practically guaranteed to be the first device so we can
>>> probably just remove the special case in addrconf_init.
>>>
>>> Anyway Daniels patch makes increasingly less sense the more I look
>>> at it.
>> Let me try to clarify:
>>
>> * when the init network namespace is created, the loopback is created first,
>> before ipv6, and the notifier call chain for ipv6 is not setup, so the protocol
>> does not receive the REGISTER event
>>
>> * when the init network namespace is destroyed during shutdown, the loopback is
>> not unregistered, so there is no UNREGISTER event
>
> * When addrconf_init calls register_netdevice_notifier we receive
> NETDEV_REGISTER and NETDEV_UP for all network devices that are in
> the system including the loopback device.
Thanks for the information. Effectively, I missed this :|
>> * when we create a new network namespace, a new instance of the loopback is
>> created and a NETDEV_REGISTER is sent to ipv6 because the notifier call chain
>> has been setup by the init netns (while ipv6 protocol is not yet configured for
>> the namespace which is being created)
>
> Possibly there may be some ordering issues here.
>
>> * when the network namespace exits, the loopback is unregistered after the ipv6
>> protocol but the NETDEV_UNREGISTER is sent to addrconf_notify while the ipv6
>> protocol has been destroyed.
>>
>>
>> The objective of the patch is to discard these events because they were never
>> taken into account and they are not expected to be receive by ipv6 protocol.
>
> My opinion is that both your analysis is slightly off (as to the cause
> of your problems) and that your approach to fix your problem is wrong
> because you don't untangle the knot you keep it.
Yes, I will look at how to fix that properly.
> ...
> I have register_pernet_subsys and register_per_net_device to ensure
> that when we create a new network namespace all of the subsystems are
> initialized before the network devices are initialize. So ipv6 should
> be ready before we initialize the new loopback device comes into
> existence.
>
> The preservation of the order of the network namespace callbacks
> ensures that the loopback device will be the first network device
> registered, and if it helps we can take advantage of that in reference
> to the weirdness from the comment below.
>
> /* The addrconf netdev notifier requires that loopback_dev
> * has it's ipv6 private information allocated and setup
> * before it can bring up and give link-local addresses
> * to other devices which are up.
> *
> * Unfortunately, loopback_dev is not necessarily the first
> * entry in the global dev_base list of net devices. In fact,
> * it is likely to be the very last entry on that list.
> * So this causes the notifier registry below to try and
> * give link-local addresses to all devices besides loopback_dev
> * first, then loopback_dev, which cases all the non-loopback_dev
> * devices to fail to get a link-local address.
> *
> * So, as a temporary fix, allocate the ipv6 structure for
> * loopback_dev first by hand.
> * Longer term, all of the dependencies ipv6 has upon the loopback
> * device and it being up should be removed.
> */
>
> We can just special case registration of the loopback device to
> do:
> ip6_null_entry.u.dst.dev = init_net.loopback_dev;
> ip6_null_entry.rt6i_idev = in6_dev_get(init_net.loopback_dev);
> #ifdef CONFIG_IPV6_MULTIPLE_TABLES
> ip6_prohibit_entry.u.dst.dev = init_net.loopback_dev;
> ip6_prohibit_entry.rt6i_idev = in6_dev_get(init_net.loopback_dev);
> ip6_blk_hole_entry.u.dst.dev = init_net.loopback_dev;
> ip6_blk_hole_entry.rt6i_idev = in6_dev_get(init_net.loopback_dev);
> #endif
>
> Which would remove the special case from addrconf_init.
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Herbert Xu @ 2007-11-13 11:09 UTC (permalink / raw)
To: Patrick McHardy
Cc: joonwpark81, davem, w, cfriesen, auke-jan.h.kok, netdev,
djohnson+linux-kernel, linux-kernel, e1000-devel
In-Reply-To: <47397AB3.90705@trash.net>
Patrick McHardy <kaber@trash.net> wrote:
>
> I still think promiscous mode should disable all filters (which would
> also provide a consistent view between accerlated and non-accerlated
> devices), but an ethtool option is better than nothing :)
I agree. People doing a tcpdump don't have to turn on promiscuous
mode, that's what the -p option is for. In other words, having
promiscuous mode disable VLAN filtering does not take away the
user's options at all.
In fact, the very definition of promiscuous is to turn off hardware
filtering, albeit the filtering of MAC addresses rather than VLAN
tags. So it would seem logical to have it turn off VLAN filtering
too.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] IPV4: add raw drops counter
From: Eric Dumazet @ 2007-11-13 11:11 UTC (permalink / raw)
To: Wang Chen; +Cc: netdev
In-Reply-To: <47397514.2070002@cn.fujitsu.com>
Wang Chen a écrit :
> Add raw drops counter for IPv4 in /proc/net/raw .
>
> Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
> ---
> include/net/sock.h | 2 ++
> net/core/sock.c | 1 +
> net/ipv4/raw.c | 16 +++++++++-------
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff -Nurp linux-2.6.24-rc2.org/include/net/sock.h linux-2.6.24-rc2/include/net/sock.h
> --- linux-2.6.24-rc2.org/include/net/sock.h 2007-11-09 16:37:08.000000000 +0800
> +++ linux-2.6.24-rc2/include/net/sock.h 2007-11-13 15:19:20.000000000 +0800
> @@ -156,6 +156,7 @@ struct sock_common {
> * @sk_prot_creator: sk_prot of original sock creator (see ipv6_setsockopt, IPV6_ADDRFORM for instance)
> * @sk_err: last error
> * @sk_err_soft: errors that don't cause failure but are the cause of a persistent failure not just 'timed out'
> + * @sk_drops: raw drops counter
> * @sk_ack_backlog: current listen backlog
> * @sk_max_ack_backlog: listen backlog set in listen()
> * @sk_priority: %SO_PRIORITY setting
> @@ -239,6 +240,7 @@ struct sock {
> rwlock_t sk_callback_lock;
> int sk_err,
> sk_err_soft;
> + atomic_t sk_drops;
>
This doesnt need an atomic_t , just an 'unsigned int' is OK, since
sock_queue_rcv_skb() is called on a locked socket.
Also, I suggest doing the sk_drops increment in sock_queue_rcv_skb() so
that it can be used for other sockets as well ?
I like having this counter per socket, but only if an application can
retrieve its value with a getsockopt() call, dont you think ?
getsockopt(sock, SOL_SOCKET, SO_DROPSCNT, &val, &vallen);
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Andrew Morton @ 2007-11-13 11:15 UTC (permalink / raw)
To: Natalie Protasevich
Cc: linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia,
linux-input, bugme-daemon
In-Reply-To: <32209efe0711122242m3a5f081asf1c11a38b24db10c@mail.gmail.com>
On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <protasnb@gmail.com> wrote:
> This is the listing of the open bugs that are relatively new, around
> 2.6.22 and up. They are vaguely classified by specific area.
> (not a full list, there are more :)
>
> The good part is that reporters of the bugs below are still around and
> haven't dissipated, or disposed of their hardware, so it is a good
> time to get the bugs.
> Those bugzillas that have been started as regressions on Rafael's list
> are not mentioned here so far, since they are being tracked as new
> regressions already.
Thanks.
> It would be appreciated if the corresponding maintenance team could take a
> look, close off any which are fixed and see if they can fix any which aren't.
>
> NOTE: when replying to this email, please add the bug number to the Subject in
> the form [Bug 1234] so that bugzilla will capture the discussion.
> Thanks.
You're optimistic.
> ACPI====================================================================
>
> System does not load without acpi=off ide=nodma noapic
> http://bugzilla.kernel.org/show_bug.cgi?id=9358
> Kernel: 2.6.23.1
One response from a developer
> ACPI Error attaching device data
> http://bugzilla.kernel.org/show_bug.cgi?id=9354
> Kernel: 2.6.24-rc2
Zero responses from developers
> /proc/acpi/battery displays Incorrect voltages
> http://bugzilla.kernel.org/show_bug.cgi?id=9341
> Kernel: 2.6.23.1
Zero responses from developers
> PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object
> http://bugzilla.kernel.org/show_bug.cgi?id=9320
> Kernel: 2.6.24-rc2
> (Tejun: calling _GTF without calling _STM first. _GTM doesn't have any
> prerequisite (it can't). Can someone familiar with ACPI tell me why the method
> is failing? At any rate, libata should work fine regardless of ACPI failures.
> Maybe it's time to start blacklist to skip ATA-ACPI for some boards to avoid
> those annoying messages during boot)
Tejun doing stuff
> ACPI Battery Info in /sys but not /proc/acpi
> http://bugzilla.kernel.org/show_bug.cgi?id=9183
> Kernel: 2.6.23-rc8-mm2
Marked as a duplicate of an already-resolved bug.
>
> When using ACPI on a Compaq Presario V6221EU the laptop goes into
> deadlock after a random amount of time
> http://bugzilla.kernel.org/show_bug.cgi?id=9118
> Kernel: 2.6.23-rc6
Someone called Jike Song is trying to help out. Regular developers awol.
>
> ACPI video driver should validate brightness level before setting it via _BCM
> http://bugzilla.kernel.org/show_bug.cgi?id=9277
> Kernel: 2.6.23
Zero responses from developers
> VIDEO/DVB
>
> dvb driver reboot system
> http://bugzilla.kernel.org/show_bug.cgi?id=9357
> Kernel: 2.6.21.5
Mauro thinks it might be bad hardware
>
> PLATFORM===============================================================
>
> xipImage is built so that uBoot cant run it (ARM)
> http://bugzilla.kernel.org/show_bug.cgi?id=9356
> Kernel: 2.6.21
Zero responses from developers
>
> Samsung R20 - ACPI: PCI Root Bridge [PCI0] (0000:00)
> http://bugzilla.kernel.org/show_bug.cgi?id=9339
> Kernel: 2.6.24
> (boot is very long
> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> then the boot stop at :
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> (during 3 minutes, and boot continue)
No response from developers
> system_64.h: switch_to inline asm should be more robbust wrt optimizations
> http://bugzilla.kernel.org/show_bug.cgi?id=9302
> Kernel: 2.6.24-rc1
Not really a bug.
> with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't
> boot (ARM, Timer)
> http://bugzilla.kernel.org/show_bug.cgi?id=9229
> Kernel: 2.6.23
No response from developers
> NETWORKING===========================================================
>
> RTNLGRP_ND_USEROPT does not report ifindex (IPv6)
> http://bugzilla.kernel.org/show_bug.cgi?id=9349
> Kernel: 2.6.24+
No response from developers
> a kernel error happend in the func: __skb_dequeue when using in
> pfifo_fast_dequeue
> http://bugzilla.kernel.org/show_bug.cgi?id=9342
> Kernel: 2.6.11.1 - reporter asked to try recent kernel
No response from developers
> e100 does not work after boot
> http://bugzilla.kernel.org/show_bug.cgi?id=9336
> Kernel: 2.6.23.1
No response from developers
> 2.6.23.1-smp kernel panic (network-related)
> http://bugzilla.kernel.org/show_bug.cgi?id=9318
> Kernel: 2.6.23.1
> Infiniband panic
No response from developers
> sundance -> 4port D-Link System Inc DFE-580TX -> Log errors
> http://bugzilla.kernel.org/show_bug.cgi?id=9311
> Kernel: 2.6.22.9
No response from developers
> via-rhine driver stalls with: PHY status 786d, resetting...
> http://bugzilla.kernel.org/show_bug.cgi?id=9300
> Kernel: 2.6.23+
No response from developers
>
> Weird network problems with 2.6.23-rc2
> http://bugzilla.kernel.org/show_bug.cgi?id=9080
> http://lkml.org/lkml/2007/8/11/40 - description
No response from developers
> rt2500pci: low TCP throughput (wireless)
> http://bugzilla.kernel.org/show_bug.cgi?id=9273
> Kernel: 2.6.24-rc1
> This is a regression
No response from developers
> Unable to build wifi network between zd1201 and b43
> http://bugzilla.kernel.org/show_bug.cgi?id=9237
> Kernel: 2.6.24-rc1
No response from developers
> Crash after module unload in b43 (wireless)
> http://bugzilla.kernel.org/show_bug.cgi?id=9233
> Kernel: 2.6.24-rc1
No response from developers
> (net typhoon) "no descs for cmd, had (needed) 0 (1) cmd, 31 (7) resp"
> http://bugzilla.kernel.org/show_bug.cgi?id=9225
> Kernel: 2.6.23.1
No response from developers
>
> IDE/SATA=========================================================
>
> pata_pdc202xx_old excessive ATA bus errors
> http://bugzilla.kernel.org/show_bug.cgi?id=9337
> 2.6.24-rc2
No response from developers
> Drive seagate ST380011AS needs to be blacklisted
> http://bugzilla.kernel.org/show_bug.cgi?id=9309
> Kernel: 2.6.22.X
Jeff and Tehun did some stuff.
> DVD-RAM umount and disk free bug
> http://bugzilla.kernel.org/show_bug.cgi?id=9265
> Kernel: 2.6.15 (asked to try current kernel)
No response from developers
> FILE SYSTEMS=======================================================
>
> ext4: delalloc space accounting problem drops data
> http://bugzilla.kernel.org/show_bug.cgi?id=9329
> Kernel: 2.6.24-rc1
No response from developers
> POSIX Access Control Lists cause bogus file system check errors
> http://bugzilla.kernel.org/show_bug.cgi?id=9241
> Kernel: 2.6.23.1
Andreas did some work, seemed to lose interest.
> MEMORY MANAGEMENT================================================
>
> My system hangs when it has no more free memory to allocate via malloc()
> http://bugzilla.kernel.org/show_bug.cgi?id=9316
> Kernel: 2.6.23
> User program, "My system hangs when it has no more free memory to
> allocate via malloc()"
Rafael poked Thomas a week ago, to no effect. Thomas has been travelling.
> BUG: unable to handle kernel paging request at virtual address
> 26121228/kswapd0[231] exited with preempt_count 1
> http://bugzilla.kernel.org/show_bug.cgi?id=9305
> EIP is at free_block+0x6d/0xe4
> Kernel: 2.6.22.6
No response from developers
> POWER MANAGEMENT==================================================
>
> IBM X41 looses time after Suspend2Disk
> http://bugzilla.kernel.org/show_bug.cgi?id=9314
> Kernel: 2.6.23
Rafael poked Thomas a week ago, to no effect. Thomas has been travelling.
> Suspend to RAM resume hangs on a tickless (NO_HZ) kernel
> http://bugzilla.kernel.org/show_bug.cgi?id=9275
> Kernel: 2.6.23
> This is HP notebook nc6320 T2400 945GM
No response from developers
>
> VIDEO DRIVERS========================================================
>
> No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
> http://bugzilla.kernel.org/show_bug.cgi?id=9310
> Kernel: 2.6.24-rc1
> This is a regression
No response from developers
>
> PARALLEL PORT========================================================
>
> LPC IT8705 POST port making noise on parallel port
> http://bugzilla.kernel.org/show_bug.cgi?id=9306
> Kernel: 2.6.16+
>
No response from developers
> I/O STORAGE===========================================================
>
> kernel bug from pktcdvd
> http://bugzilla.kernel.org/show_bug.cgi?id=9294
> Kernel: 2.6.23
I think we might have fixed this.
> After pci-e video card was installed, pci add-on usb card & firewire card fail
> http://bugzilla.kernel.org/show_bug.cgi?id=9223
> Kernel: 2.6.20 (testing of latest kernel requested)
No response from developers
> SCSI==================================================================
>
> qla2xxx: driver initialization does not complete when booting with
> Port connected
> http://bugzilla.kernel.org/show_bug.cgi?id=9267
> Kernel: 2.6.23.1
No response from developers
> SOUND ALSA============================================================
>
> Unable to load snd-hda-intel module: Unknown symbol in module, or
> unknown parameter
> http://bugzilla.kernel.org/show_bug.cgi?id=9242
> Kernel: 2.6.24-rc1
Takashi has responded
> usbaudio microphone: regular sound distortion on several Logitech Webcams
> http://bugzilla.kernel.org/show_bug.cgi?id=9230
> Kernel: 2.6.22.9
Clemens responded
> HID====================================================================
>
> Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc
> http://bugzilla.kernel.org/show_bug.cgi?id=9216
> Kernel: 2.6.23.1
> Looks like this is a regression
No response from developers
So I count around seven reports which people are doing something with and
twenty seven which have been just ignored.
Three of these reports have been identified as regressions. All three
of those remain unresponded to.
^ permalink raw reply
* Re: [PATCH] prevent that myri_do_handshake lies about ticks in drivers/net/myri_sbus.c
From: David Miller @ 2007-11-13 11:16 UTC (permalink / raw)
To: 12o3l; +Cc: netdev
In-Reply-To: <472F3163.2060302@tiscali.nl>
From: Roel Kluin <12o3l@tiscali.nl>
Date: Mon, 05 Nov 2007 16:06:11 +0100
> With '<=' tick can be incremented up to 26, The last loop is redundant since
> even when 'softstate' becomes 'STATE_READY', 'if (tick > 25)' will still cause
> the function to return -1,
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH] Fix incorrect usage of strncat in bdx_get_drvinfo(); drivers/net/tehuti.c
From: David Miller @ 2007-11-13 11:17 UTC (permalink / raw)
To: 12o3l; +Cc: netdev
In-Reply-To: <472F807B.3050901@tiscali.nl>
From: Roel Kluin <12o3l@tiscali.nl>
Date: Mon, 05 Nov 2007 21:43:39 +0100
> Fix incorrect length for strncat by replacing it with strlcat
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] cleanup pernet operation without CONFIG_NET_NS
From: David Miller @ 2007-11-13 11:24 UTC (permalink / raw)
To: den; +Cc: devel, containers, netdev, clg, benjamin.thery
In-Reply-To: <20071107120007.GA10169@iris.sw.ru>
From: "Denis V. Lunev" <den@openvz.org>
Date: Wed, 7 Nov 2007 15:00:07 +0300
> If CONFIG_NET_NS is not set, the only namespace is possible.
>
> This patch removes list of pernet_operations and cleanups code a bit.
> This list is not needed if there are no namespaces. We should just call
> ->init method.
>
> Additionally, the ->exit will be called on module unloading only. This
> case is safe - the code is not discarded. For the in/kernel code, ->exit
> should never be called.
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox