* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: J�rn Engel @ 2010-03-27 22:00 UTC (permalink / raw)
To: Robert Hancock; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <4BAE4464.9060909@gmail.com>
On Sat, 27 March 2010 11:46:12 -0600, Robert Hancock wrote:
>
> Hm, do you recall/have the details of what happened with the other card?
It lost interrupts. I had a testcase that should have received three
interrupts and only two were received by the driver. 100%
reproducable. Card used MSI-Interrupts (no MSI-X) and worked
reasonably well otherwise. But it is a prototype, so the card is just
as likely to be the cause as the motherboard.
> It's possible this is some general problem with that machine/motherboard
> and not actually an issue with what the driver is doing. What kind of
> board is that?
Possible, yes. But I wouldn't know how to prove it.
Asrock G31M-S with Intel E5200.
J�rn
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 21:11 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BAE6C92.2060801@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> Any ideas how to check this?
Check the datasheet of VIA's chipset for a WC control bit - there
ought to be one - and disable it.
> Or is swapping MAC0/MAC4 writes, or adding the extra read an
> acceptable fix/workaround?
swapping should reliably disable WC. It would be fine.
--
Ueimor
^ permalink raw reply
* [PATCH kernel 2.6.34-rc2] pcnet_cs: add new id
From: Ken Kawasaki @ 2010-03-27 20:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100228083420.9ca8e285.ken_kawasaki@spring.nifty.jp>
pcnet_cs:
*add new id (Allied Telesis LM33-PCM-T Lan&Modem multifunction card)
*use PROD_ID for LA-PCM.(because LA-PCM and LM33-PCM-T use the same MANF_ID).
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.34-rc2/drivers/net/pcmcia/pcnet_cs.c.orig 2010-03-21 20:39:59.000000000 +0900
+++ linux-2.6.34-rc2/drivers/net/pcmcia/pcnet_cs.c 2010-03-27 14:42:34.000000000 +0900
@@ -1549,6 +1549,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_PFC_DEVICE_MANF_CARD(0, 0x021b, 0x0101),
PCMCIA_PFC_DEVICE_MANF_CARD(0, 0x08a1, 0xc0ab),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "AnyCom", "Fast Ethernet + 56K COMBO", 0x578ba6e7, 0xb0ac62c4),
+ PCMCIA_PFC_DEVICE_PROD_ID12(0, "ATKK", "LM33-PCM-T", 0xba9eb7e2, 0x077c174e),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "D-Link", "DME336T", 0x1a424a1c, 0xb23897ff),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "Grey Cell", "GCS3000", 0x2a151fac, 0x48b932ae),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "Linksys", "EtherFast 10&100 + 56K PC Card (PCMLM56)", 0x0733cc81, 0xb3765033),
@@ -1740,7 +1741,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_MFC_DEVICE_CIS_PROD_ID12(0, "DAYNA COMMUNICATIONS", "LAN AND MODEM MULTIFUNCTION", 0x8fdf8f89, 0xdd5ed9e8, "cis/DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID4(0, "NSC MF LAN/Modem", 0x58fc6056, "cis/DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(0, 0x0175, 0x0000, "cis/DP83903.cis"),
- PCMCIA_DEVICE_CIS_MANF_CARD(0xc00f, 0x0002, "cis/LA-PCM.cis"),
+ PCMCIA_DEVICE_CIS_PROD_ID12("Allied Telesis,K.K", "Ethernet LAN Card", 0x2ad62f3c, 0x9fd2f0a2, "cis/LA-PCM.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("KTI", "PE520 PLUS", 0xad180345, 0x9d58d392, "cis/PE520.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("NDC", "Ethernet", 0x01c43ae1, 0x00b2e941, "cis/NE2K.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("PMX ", "PE-200", 0x34f3f1c8, 0x10b59f8c, "cis/PE-200.cis"),
--- linux-2.6.34-rc2/drivers/serial/serial_cs.c.orig 2010-03-22 06:53:31.000000000 +0900
+++ linux-2.6.34-rc2/drivers/serial/serial_cs.c 2010-03-27 14:42:53.000000000 +0900
@@ -745,6 +745,7 @@ static struct pcmcia_device_id serial_id
PCMCIA_PFC_DEVICE_PROD_ID13(1, "Xircom", "REM10", 0x2e3ee845, 0x76df1d29),
PCMCIA_PFC_DEVICE_PROD_ID13(1, "Xircom", "XEM5600", 0x2e3ee845, 0xf1403719),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "AnyCom", "Fast Ethernet + 56K COMBO", 0x578ba6e7, 0xb0ac62c4),
+ PCMCIA_PFC_DEVICE_PROD_ID12(1, "ATKK", "LM33-PCM-T", 0xba9eb7e2, 0x077c174e),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "D-Link", "DME336T", 0x1a424a1c, 0xb23897ff),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "Gateway 2000", "XJEM3336", 0xdd9989be, 0x662c394c),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "Grey Cell", "GCS3000", 0x2a151fac, 0x48b932ae),
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 20:37 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADFAE4.5040906@iki.fi>
Timo Teräs wrote:
> François Romieu wrote:
>> Timo Teräs <timo.teras@iki.fi> :
>> [...]
>>> It seems that adding single printk between writing MAC0 and MAC4
>>> fixes it.
>>> I guess it needs a bit of delay between the writes or something.
>>
>> Can you test with a single RTL_R32 after each MACx write ?
>
> Adding reading back of the written value fixes it too. Though,
> disassembly says that it added an extra instructions also (needs to
> load the 'high' from stack before writing it) so the added delay is
> probably slightly more than just the io read.
I'm not too familiar with PCI details, but this smells a bit
like that write-combining is happening and the NIC does not like
that.
Any ideas how to check this?
The system experiencing this is a "VIA Eden 1.2Ghz" box.
Or is swapping MAC0/MAC4 writes, or adding the extra read an
acceptable fix/workaround?
- Timo
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: Robert Hancock @ 2010-03-27 17:46 UTC (permalink / raw)
To: � Engel; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <20100327063838.GB11959@Dublin.logfs.org>
On 03/27/2010 12:38 AM, � Engel wrote:
> On Fri, 26 March 2010 19:55:44 -0600, Robert Hancock wrote:
>>
>> Well, that one's 36 bits, but it's unclear whether that driver would
>> actually be likely to access anything over 4GB. It's possible that
>> there's just some general problem with 64-bit DMA on that machine.
>
> That may very well be. I've had trouble using a PCIe card in that
> machine as well. "Solution" was to buy a different computer. Sad, I
> know, but not my money.
Hm, do you recall/have the details of what happened with the other card?
It's possible this is some general problem with that machine/motherboard
and not actually an issue with what the driver is doing. What kind of
board is that?
>
>> The fact that even stuff like lspci and MII is breaking seems odd,
>> though. It could be that model of card doesn't like the PCIDAC register
>> bit being set (maybe it means something different on that model, or
>> something).
>>
>> I suppose a publicly accessible datasheet for these chips is too much to
>> hope for?
>
> Which chips?
>
> J�rn
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: CVE-2009-4537
From: David Miller @ 2010-03-27 17:36 UTC (permalink / raw)
To: michael.s.gilbert; +Cc: linux-kernel, netdev, nhorman
In-Reply-To: <20100327.103407.260084965.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 27 Mar 2010 10:34:07 -0700 (PDT)
> From: Michael Gilbert <michael.s.gilbert@gmail.com>
> Date: Sat, 27 Mar 2010 14:21:00 -0400
>
>> Hi,
>>
>> CVE-2009-4537 has been disclosed without any upstream activity for a
>> while now. Discussion about the issue dried up in January [0], and a
>> patch had been proposed [1], but no arguments were seen either for or
>> against it. Note that redhat has already shipped that in their various
>> kernel security updates. Would it make sense to merge those changes
>> officially?
>
> A different version of the fix went into the tree.
Ignore me, that was a fix for a different problem.
I was waiting for Francois to come up with a cleaner fix
but he stopped working on it, so yes I should put in
the fix you mention or something similar.
Neil, can you formally submit a version of the r8169
CVE for upstream?
Thanks.
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Martin Sustrik @ 2010-03-27 16:54 UTC (permalink / raw)
To: Andi Kleen; +Cc: Christoph Lameter, David Miller, netdev, linux-kernel
In-Reply-To: <20100327131138.GD20695@one.firstfloor.org>
Andi Kleen wrote:
> I did a quick read and the manpage/interface seem reasonable to me.
You may also have a look at original PGM implementation by Luigi Rizzo
(FreeBSD). It's not maintained, but it might give you broader view.
http://info.iet.unipi.it/~luigi/pgm-code/
Martin
^ permalink raw reply
* Re: [PATCH 6/9] drivers/net: Fix continuation lines
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, jcliburn, chris.snook, jie.yang, atl1-devel, netdev
In-Reply-To: <6b7a0c43891d5af5796b681898d901bbf2e1cda1.1269655208.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 26 Mar 2010 19:27:55 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000: do not modify tx_queue_len on link speed change
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, franco, emil.s.tantilov, jesse.brandeburg
In-Reply-To: <20100326212557.18793.62063.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 26 Mar 2010 14:25:58 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Previously the driver tweaked txqueuelen to avoid false Tx hang reports
> seen at half duplex. This had the effect of overriding user set values
> on link change/reset. Testing shows that adjusting only the timeout
> factor is sufficient to prevent Tx hang reports at half duplex.
>
> This patch removes all instances of tx_queue_len in the driver.
>
> Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>
>
> CC: Franco Fichtner <franco@lastsummer.de>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4BACECA6.2050506@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 26 Mar 2010 18:19:34 +0100
> When a multicast packet arrived in ip6_mr_input(), if there is no
> cache ip6mr_cache_unresolved() will be called and this function will
> add an entry with parent == 65535.
>
> And the second problem is that when a vif is removed, no cleanup is
> made in cache entry. Hence, we can have a cache entry which points to
> an invalid vif (dev is set ot NULL).
I've applied your fix, thanks Nicolas.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: Do not run all Diagnostic offline tests when VFs are active
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100326030647.10085.16720.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:06:48 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> When running the offline diagnostic tests check to see if any VFs are
> online. If so then only run the link test. This is necessary because
> the VFs running in guest VMs aren't aware of when the PF is taken
> offline for a diagnostic test. Also put a message to the system log
> telling the system administrator to take the VFs offline manually if
> (s)he wants to run a full diagnostic. Return 1 on each of the tests
> not run to alert the user of the condition.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] igb: use correct bits to identify if managability is enabled
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100326031506.10368.40559.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:15:06 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> igb was previously checking the wrong bits in the MANC register to determine
> if managability was enabled. As a result it was incorrectly powering down and
> resetting the phy when it didn't need to.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] benet: Fix compile warnnings in drivers/net/benet/be_ethtool.c
From: David Miller @ 2010-03-27 15:32 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: wzt.wzt, linux-kernel, netdev, linux-drivers, sathyap
In-Reply-To: <20100326171616.GA20879@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Fri, 26 Mar 2010 22:46:18 +0530
> On 26/03/10 14:12 +0800, wzt.wzt@gmail.com wrote:
>> Fix the following warnings:
>>
>> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>>
>> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
>
> I would suggest using be2net instead of benet during the commit.
> be2net: Fix compile warnnings in drivers/net/benet/be_ethtool.c
>
> Acked-by: Ajit Khaparde <ajitk@serverengines.com>
Well, you cannot be surprised that people will use "benet"
since that is the name of the directory the driver lives
under. It is not even referred to as "be2net" in the
MAINTAINERS entry.
I'm applying this fix as-is.
^ permalink raw reply
* Re: [PATCH v2] Add MSG_WAITFORONE flag to recvmmsg
From: David Miller @ 2010-03-27 15:29 UTC (permalink / raw)
To: acme; +Cc: blblack, netdev, drepper, linux-kernel
In-Reply-To: <20100327140717.GN3625@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Sat, 27 Mar 2010 11:07:17 -0300
> Em Fri, Mar 26, 2010 at 08:54:28PM -0700, David Miller escreveu:
>> From: Brandon L Black <blblack@gmail.com>
>> Date: Fri, 26 Mar 2010 21:18:03 -0500
>>
>> >
>> > From: Brandon L Black <blblack@gmail.com>
>> >
>> > Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
>> > When this flag is specified for a blocking socket, recvmmsg()
>> > will only block until at least 1 packet is available. The
>> > default behavior is to block until all vlen packets are
>> > available. This flag has no effect on non-blocking sockets
>> > or when used in combination with MSG_DONTWAIT.
>> >
>> > Signed-off-by: Brandon L Black <blblack@gmail.com>
>>
>> Arnaldo, please review this, thanks.
>
> I'm ok with it.
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Regression in virtio_net causing kernel BUG when running under VirtualBox (bisected)
From: Thomas Müller @ 2010-03-27 14:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Thomas Müller
[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]
Hello,
I'm running Linux under VirtualBox 3.1.6 with a single virtual CPU
without any third party drivers.
Commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399
(virtio_net: Defer skb allocation in receive path)
caused a regression which results in a kernel bug and subsequent
hang at every boot.
I have attached the complete output during boot.
Please CC me on reply as I'm not subscribed to the mailing lists.
Best regards,
Thomas
------------[ cut here ]------------
kernel BUG at include/linux/scatterlist.h:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/tty/tty56/uevent
CPU 0
Pid: 299, comm: modprobe Not tainted 2.6.33-rc5-00614-g9ab86bb #15 /VirtualBox
RIP: 0010:[<ffffffffa0026271>] [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP: 0000:ffff88007a615bd8 EFLAGS: 00010286
RAX: ffffea0001ac86b0 RBX: ffff88007a615c18 RCX: 0000000087654321
RDX: 0000000000000246 RSI: ffff88007a6fa2b0 RDI: ffff88007a6fa2b0
RBP: ffff88007a615bf8 R08: 0000000000000020 R09: 0000000000000640
R10: ffff88007a615c08 R11: ffff88007d098000 R12: ffff88007a6fa2b0
R13: 000000000000000a R14: 0000160000000000 R15: ffff88007a615c98
FS: 00007f9d6b27c700(0000) GS:ffff880004a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fec3fcd72c0 CR3: 000000007a43c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 299, threadinfo ffff88007a614000, task ffff88007b8b2470)
Stack:
ffff88007a615bf8 ffff88007a6fa280 ffff88007a615c18 ffff88007b980880
<0> ffff88007a615c88 ffffffffa0026a08 ffff88007a615c18 ffffffff8107d5c1
<0> ffff88007a615c48 0000000000000246 0000000000000010 ffff88007b980000
Call Trace:
[<ffffffffa0026a08>] add_recvbuf_small+0x66/0xac [virtio_net]
[<ffffffff8107d5c1>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81454932>] ? mutex_unlock+0xe/0x10
[<ffffffff813ccae6>] ? __rtnl_unlock+0x15/0x17
[<ffffffffa0026b55>] try_fill_recv+0x107/0x155 [virtio_net]
[<ffffffff813ccacf>] ? rtnl_unlock+0xe/0x10
[<ffffffffa0026f6b>] virtnet_probe+0x3c8/0x46f [virtio_net]
[<ffffffffa0026151>] ? skb_recv_done+0x0/0x3f [virtio_net]
[<ffffffffa002610d>] ? skb_xmit_done+0x0/0x44 [virtio_net]
[<ffffffffa000007c>] ? add_status+0x32/0x3a [virtio]
[<ffffffffa00002df>] virtio_dev_probe+0xb7/0xdb [virtio]
[<ffffffff812e30a3>] driver_probe_device+0xed/0x21a
[<ffffffff812e322d>] __driver_attach+0x5d/0x81
[<ffffffff812e31d0>] ? __driver_attach+0x0/0x81
[<ffffffff812e2507>] bus_for_each_dev+0x59/0x8e
[<ffffffff812e2e2a>] driver_attach+0x1e/0x20
[<ffffffff812e2a4a>] bus_add_driver+0xd8/0x242
[<ffffffff812e3534>] driver_register+0x9e/0x10f
[<ffffffffa000b000>] ? init+0x0/0x12 [virtio_net]
[<ffffffffa0000441>] register_virtio_driver+0x27/0x2a [virtio]
[<ffffffffa000b010>] init+0x10/0x12 [virtio_net]
[<ffffffff8100207d>] do_one_initcall+0x72/0x18a
[<ffffffff8108b116>] sys_init_module+0xd8/0x23a
[<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
Code: 49 89 f4 e8 f2 ce 00 e1 48 c1 e8 0c 48 b9 00 00 00 00 00 ea ff ff 48 8b 53 08 48 6b c0 38 48
01 c8 b9 21 43 65 87 48 39 0b 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 41 81 e4 ff 0f
RIP [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP <ffff88007a615bd8>
---[ end trace 0110e718da6da1ad ]---
[-- Attachment #2: boot.txt --]
[-- Type: text/plain, Size: 18065 bytes --]
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.33-rc5-00614-g9ab86bb (thomas@Rawhide-virt) (gcc version 4.4.3 20100226 (Red Hat 4.4.3-8) (GCC) ) #15 SMP Sat Mar 27 14:09:46 CET 2010
Command line: ro root=UUID=5bd27a38-a65f-451b-ad4d-096afb2dff69 LANG=de_DE.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1 vga=0x307 console=tty0 console=ttyS0,9600n8
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
BIOS-e820: 000000007fff0000 - 0000000080000000 (ACPI data)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
NX (Execute Disable) protection: active
DMI 2.5 present.
No AGP bridge found
last_pfn = 0x7fff0 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
CPU MTRRs all blank - virtualized system.
found SMP MP-table at [ffff88000009fff0] 9fff0
init_memory_mapping: 0000000000000000-000000007fff0000
RAMDISK: 37c37000 - 37fef3d1
ACPI: RSDP 00000000000e0000 00024 (v02 VBOX )
ACPI: XSDT 000000007fff0030 00034 (v01 VBOX VBOXXSDT 00000001 ASL 00000061)
ACPI: FACP 000000007fff00f0 000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061)
ACPI: DSDT 000000007fff0270 01A0C (v01 VBOX VBOXBIOS 00000002 INTL 20050309)
ACPI: FACS 000000007fff01f0 00040
ACPI: APIC 000000007fff0230 00040 (v02 VBOX VBOXAPIC 00000001 ASL 00000061)
No NUMA configuration found
Faking a node at 0000000000000000-000000007fff0000
Bootmem setup node 0 0000000000000000-000000007fff0000
NODE_DATA [000000000000a000 - 0000000000022fff]
bootmap [0000000000023000 - 0000000000032fff] pages 10
(12 early reservations) ==> bootmem [0000000000 - 007fff0000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0001000000 - 00029b3020] TEXT DATA BSS ==> [0001000000 - 00029b3020]
#2 [0037c37000 - 0037fef3d1] RAMDISK ==> [0037c37000 - 0037fef3d1]
#3 [00029b4000 - 00029b4071] BRK ==> [00029b4000 - 00029b4071]
#4 [000009fc00 - 000009fff0] BIOS reserved ==> [000009fc00 - 000009fff0]
#5 [000009fff0 - 00000a0000] MP-table mpf ==> [000009fff0 - 00000a0000]
#6 [00000a0000 - 00000e1160] BIOS reserved ==> [00000a0000 - 00000e1160]
#7 [00000e1230 - 0000100000] BIOS reserved ==> [00000e1230 - 0000100000]
#8 [00000e1160 - 00000e1230] MP-table mpc ==> [00000e1160 - 00000e1230]
#9 [0000001000 - 0000003000] TRAMPOLINE ==> [0000001000 - 0000003000]
#10 [0000003000 - 0000007000] ACPI WAKEUP ==> [0000003000 - 0000007000]
#11 [0000008000 - 000000a000] PGTABLE ==> [0000008000 - 000000a000]
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x0000009f
0: 0x00000100 -> 0x0007fff0
ACPI: PM-Timer IO Port: 0x4008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 1 CPUs, 0 hotplug CPUs
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 80000000 (gap: 80000000:7ffc0000)
Booting paravirtualized kernel on bare hardware
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 478 pages/cpu @ffff880004a00000 s1927256 r8192 d22440 u2097152
pcpu-alloc: s1927256 r8192 d22440 u2097152 alloc=1*2097152
pcpu-alloc: [0] 0
Built 1 zonelists in Node order, mobility grouping on. Total pages: 516903
Policy zone: DMA32
Kernel command line: ro root=UUID=5bd27a38-a65f-451b-ad4d-096afb2dff69 LANG=de_DE.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1 vga=0x307 console=tty0 console=ttyS0,9600n8
PID hash table entries: 4096 (order: 3, 32768 bytes)
Checking aperture...
No AGP bridge found
Memory: 2035136k/2097088k available (4471k kernel code, 388k absent, 61564k reserved, 7461k data, 2744k init)
SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:4352 nr_irqs:256
Console: colour dummy device 80x25
console [tty0] enabled
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 6367 kB
per task-struct memory footprint: 2688 bytes
allocated 20971520 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Fast TSC calibration using PIT
Detected 2969.177 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 5938.35 BogoMIPS (lpj=2969177)
Security Framework initialized
SELinux: Initializing.
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
mce: CPU supports 0 MCE banks
using mwait in idle threads.
Performance Events: unsupported p6 CPU model 23 no PMU driver, software events only.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 29k freed
ACPI: Core revision 20091214
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 21066 entries in 83 pages
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
CPU0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz stepping 06
Brought up 1 CPUs
Total of 1 processors activated (5938.35 BogoMIPS).
devtmpfs: initialized
regulator: core version 0.5
Time: 14:29:24 Date: 03/27/10
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci_root PNP0A03:00: ignoring host bridge windows from ACPI; boot with "pci=use_crs" to use them
ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 9 *10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *9 10 11)
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
Switching to clocksource tsc
kstop/0 used greatest stack depth: 6424 bytes left
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 6 devices
ACPI: ACPI bus type pnp unregistered
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 10, 4718592 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
UDP hash table entries: 1024 (order: 5, 163840 bytes)
UDP-Lite hash table entries: 1024 (order: 5, 163840 bytes)
NET: Registered protocol family 1
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: Activating ISA DMA hang workarounds
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3808k freed
DMA-API: preallocated 32768 debug entries
DMA-API: debugging enabled by kernel config
platform rtc_cmos: registered platform RTC device (no PNP device found)
Intel PCLMULQDQ-NI instructions are not detected.
audit: initializing netlink socket (disabled)
type=2000 audit(1269700164.597:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
EXT4-fs: Unable to register as ext3 (-16)
msgmni has been set to 3982
cryptomgr_test used greatest stack depth: 5880 bytes left
cryptomgr_test used greatest stack depth: 5592 bytes left
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
pci-stub: invalid id string ""
vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90000d00000, using 2560k, total 32768k
vesafb: mode is 1280x1024x8, linelength=1280, pages=5
vesafb: scrolling: redraw
vesafb: Pseudocolor: size=8:8:8:8, shift=0:0:0:0
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [AC] (on-line)
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ÿserial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input2
ahci 0000:00:0d.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
ahci: SSS flag set, parallel bus scan disabled
ahci 0000:00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
ahci 0000:00:0d.0: flags: 64bit ncq stag only ccc
scsi0 : ahci
ata1: SATA max UDMA/133 abar m8192@0xf0406000 port 0xf0406100 irq 21
scsi1 : ata_piix
scsi2 : ata_piix
ata2: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xd000 irq 14
ata3: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xd008 irq 15
Fixed MDIO Bus: probed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
ehci_hcd 0000:00:0b.0: EHCI Host Controller
ehci_hcd 0000:00:0b.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0b.0: irq 19, io mem 0xf0405000
ehci_hcd 0000:00:0b.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.33-rc5-00614-g9ab86bb ehci_hcd
usb usb1: SerialNumber: 0000:00:0b.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:06.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
ohci_hcd 0000:00:06.0: OHCI Host Controller
ohci_hcd 0000:00:06.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:06.0: irq 22, io mem 0xf0404000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.33-rc5-00614-g9ab86bb ohci_hcd
usb usb2: SerialNumber: 0000:00:06.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 8 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, 114 bytes nvram
device-mapper: uevent: version 1.0.3
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4
device-mapper: ioctl: 4.16.0-ioctl (2009-11-05) initialised: dm-devel@redhat.com
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 17
registered taskstats version 1
No TPM chip found, activating TPM-bypass!
Magic number: 2:421:486
rtc_cmos rtc_cmos: setting system clock to 2010-03-27 14:29:25 UTC (1269700165)
Initalizing network drop monitor service
ata3.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133
ata3.00: configured for UDMA/100
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133
ata1.00: 104857600 sectors, multi 128: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 2:0:0:0: CD-ROM VBOX CD-ROM 1.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 104857600 512-byte logical blocks: (53.6 GB/50.0 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sr0: scsi3-mmc drive: 32x/32x xa/form2 tray
Uniform CD-ROM driver Revision: 3.20
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sr 2:0:0:0: Attached scsi generic sg1 type 5
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
Freeing unused kernel memory: 2744k freed
Write protecting the kernel read-only data: 10240k
Freeing unused kernel memory: 1652k freed
Freeing unused kernel memory: 1880k freed
mknod used greatest stack depth: 5424 bytes left
dracut: dracut-005-1.fc14
udevd used greatest stack depth: 5048 bytes left
udev: starting version 151
dracut: Starting plymouth daemon
^[%Gscsi_id used greatest stack depth: 4192 bytes left
virtio-pci 0000:00:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
async/2 used greatest stack depth: 3800 bytes left
^[%GEXT4-fs (sda3): mounted filesystem with ordered data mode
dracut: Mounted root filesystem /dev/sda3
dracut: Switching root
Welcome to Fedora
Press 'I' to enter interactive startup.
udev starten: ------------[ cut here ]------------
kernel BUG at include/linux/scatterlist.h:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/tty/tty56/uevent
CPU 0
Pid: 299, comm: modprobe Not tainted 2.6.33-rc5-00614-g9ab86bb #15 /VirtualBox
RIP: 0010:[<ffffffffa0026271>] [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP: 0000:ffff88007a615bd8 EFLAGS: 00010286
RAX: ffffea0001ac86b0 RBX: ffff88007a615c18 RCX: 0000000087654321
RDX: 0000000000000246 RSI: ffff88007a6fa2b0 RDI: ffff88007a6fa2b0
RBP: ffff88007a615bf8 R08: 0000000000000020 R09: 0000000000000640
R10: ffff88007a615c08 R11: ffff88007d098000 R12: ffff88007a6fa2b0
R13: 000000000000000a R14: 0000160000000000 R15: ffff88007a615c98
FS: 00007f9d6b27c700(0000) GS:ffff880004a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fec3fcd72c0 CR3: 000000007a43c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 299, threadinfo ffff88007a614000, task ffff88007b8b2470)
Stack:
ffff88007a615bf8 ffff88007a6fa280 ffff88007a615c18 ffff88007b980880
<0> ffff88007a615c88 ffffffffa0026a08 ffff88007a615c18 ffffffff8107d5c1
<0> ffff88007a615c48 0000000000000246 0000000000000010 ffff88007b980000
Call Trace:
[<ffffffffa0026a08>] add_recvbuf_small+0x66/0xac [virtio_net]
[<ffffffff8107d5c1>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81454932>] ? mutex_unlock+0xe/0x10
[<ffffffff813ccae6>] ? __rtnl_unlock+0x15/0x17
[<ffffffffa0026b55>] try_fill_recv+0x107/0x155 [virtio_net]
[<ffffffff813ccacf>] ? rtnl_unlock+0xe/0x10
[<ffffffffa0026f6b>] virtnet_probe+0x3c8/0x46f [virtio_net]
[<ffffffffa0026151>] ? skb_recv_done+0x0/0x3f [virtio_net]
[<ffffffffa002610d>] ? skb_xmit_done+0x0/0x44 [virtio_net]
[<ffffffffa000007c>] ? add_status+0x32/0x3a [virtio]
[<ffffffffa00002df>] virtio_dev_probe+0xb7/0xdb [virtio]
[<ffffffff812e30a3>] driver_probe_device+0xed/0x21a
[<ffffffff812e322d>] __driver_attach+0x5d/0x81
[<ffffffff812e31d0>] ? __driver_attach+0x0/0x81
[<ffffffff812e2507>] bus_for_each_dev+0x59/0x8e
[<ffffffff812e2e2a>] driver_attach+0x1e/0x20
[<ffffffff812e2a4a>] bus_add_driver+0xd8/0x242
[<ffffffff812e3534>] driver_register+0x9e/0x10f
[<ffffffffa000b000>] ? init+0x0/0x12 [virtio_net]
[<ffffffffa0000441>] register_virtio_driver+0x27/0x2a [virtio]
[<ffffffffa000b010>] init+0x10/0x12 [virtio_net]
[<ffffffff8100207d>] do_one_initcall+0x72/0x18a
[<ffffffff8108b116>] sys_init_module+0xd8/0x23a
[<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
Code: 49 89 f4 e8 f2 ce 00 e1 48 c1 e8 0c 48 b9 00 00 00 00 00 ea ff ff 48 8b 53 08 48 6b c0 38 48 01 c8 b9 21 43 65 87 48 39 0b 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 41 81 e4 ff 0f
RIP [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP <ffff88007a615bd8>
---[ end trace 0110e718da6da1ad ]---
^[%Gparport_pc 00:05: reported by Plug and Play ACPI
ppdev: user-space parallel port driver
udevd-work[270]: '/sbin/modprobe -b virtio:d00000001v00001AF4' unexpected exit with status 0x000b
[ OK ]
Rechnername Rawhide-virt einstellen: [ OK ]
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Arnaldo Carvalho de Melo @ 2010-03-27 14:26 UTC (permalink / raw)
To: Brandon Black; +Cc: Chris Friesen, linux-kernel, netdev
In-Reply-To: <84621a61003270619p6b4fe81bi24bb1961aba77ffb@mail.gmail.com>
Em Sat, Mar 27, 2010 at 08:19:09AM -0500, Brandon Black escreveu:
> On Wed, Mar 24, 2010 at 2:55 PM, Brandon Black <blblack@gmail.com> wrote:
> > On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@nortel.com> wrote:
> >> Consider the case where you want to do some other useful work in
> >> addition to running your network server. Every cpu cycle spent on the
> >> network server is robbed from the other work. In this scenario you want
> >> to handle packets as efficiently as possible, so the timeout-based
> >> behaviour is better since it is more likely to give you multiple packets
> >> per syscall.
> >
> > That's a good point, I tend to tunnelvision on the dedicated server
> > scenario. I should probably have a user-level option for
> > timeout-based operation as well, since the decision here gets to the
> > systems admin/engineering level and will be situational.
>
> I've been playing with the timeout argument to recvmmsg as well now,
> and I'm struggling to see how one would ever use it correctly with the
> current implementation. It seems to rely on the assumption of a
> never-ending stream of tightly-spaced input packets? It seems like it
As said by somebody else in this recent discussion (perhaps Chris), it
is based on the maximum latency acceptable.
If minimum latency is desired, use a zero timeout and get as many
packets get queued up while the application is processing the last
batch.
If instead more packets are desired per batch and some latency is
acceptable, use a timeout.
10 Gbit/s interfaces were the target but results with simple app
published when the syscall was posted initially showed that even on 1
1 Gbit/s eth this helped.
> was meant for usage on blocking sockets. Given a blocking socket with
> timeout 0 (infinite), and a recvmmsg timeout of 100us, if you had a
> very steady stream of input packets, it recvmmsg would pull in all of
> them that it could within a max timeframe of (100us +
> time_to_execute_one_recvmsg). However, any disruption to the input
> stream for a time-window of N would result in delaying some
> already-received packets by N. For example, consider the case that 2
> packets are already queued when you invoke recvmmsg(), but then the
> next packet doesn't arrive for another 300ms. In this scenario, you'd
> end up with recvmmsg() blocking for 300ms and then returning all 3
> packets, two of which have been delayed way beyond the specified
> timeout.
And that is a use case that is fixed by your patch, thanks, now we cover
more use cases :-)
- Arnaldo
^ permalink raw reply
* Re: Does Realtek RTL8110S and RTL8100C work ?
From: Jan Ceuleers @ 2010-03-27 14:12 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hoiqcr$dhl$1@dough.gmane.org>
Markus Feldmann wrote:
> Thanks for you answer Jan,
>
> do you know the developer e-mail adress?
> So 1000Mbit/s is not possible at the moment, but does it work stable?
>
> regards Markus
Markus,
You misunderstood. The first of the interfaces I listed is operating at 1Gbit/s; the second is only operating at 100Mbit/s because the device it is connected to (on the other end of the Ethernet cable) is not capable of anything faster.
I have no reliability issues with these network interfaces. Note though that my mainboard is quite low-end (Via C7 1.5GHz), so that the network interfaces never really get stressed.
Jan
^ permalink raw reply
* Re: [PATCH v2] Add MSG_WAITFORONE flag to recvmmsg
From: Arnaldo Carvalho de Melo @ 2010-03-27 14:07 UTC (permalink / raw)
To: David Miller; +Cc: blblack, netdev, drepper, linux-kernel
In-Reply-To: <20100326.205428.44779758.davem@davemloft.net>
Em Fri, Mar 26, 2010 at 08:54:28PM -0700, David Miller escreveu:
> From: Brandon L Black <blblack@gmail.com>
> Date: Fri, 26 Mar 2010 21:18:03 -0500
>
> >
> > From: Brandon L Black <blblack@gmail.com>
> >
> > Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
> > When this flag is specified for a blocking socket, recvmmsg()
> > will only block until at least 1 packet is available. The
> > default behavior is to block until all vlen packets are
> > available. This flag has no effect on non-blocking sockets
> > or when used in combination with MSG_DONTWAIT.
> >
> > Signed-off-by: Brandon L Black <blblack@gmail.com>
>
> Arnaldo, please review this, thanks.
I'm ok with it.
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
- Arnaldo
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Brandon Black @ 2010-03-27 13:19 UTC (permalink / raw)
To: Chris Friesen, Arnaldo Carvalho de Melo; +Cc: linux-kernel, netdev
In-Reply-To: <84621a61003241255i74282f53v3bb0111808895401@mail.gmail.com>
On Wed, Mar 24, 2010 at 2:55 PM, Brandon Black <blblack@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@nortel.com> wrote:
>> Consider the case where you want to do some other useful work in
>> addition to running your network server. Every cpu cycle spent on the
>> network server is robbed from the other work. In this scenario you want
>> to handle packets as efficiently as possible, so the timeout-based
>> behaviour is better since it is more likely to give you multiple packets
>> per syscall.
>
> That's a good point, I tend to tunnelvision on the dedicated server
> scenario. I should probably have a user-level option for
> timeout-based operation as well, since the decision here gets to the
> systems admin/engineering level and will be situational.
I've been playing with the timeout argument to recvmmsg as well now,
and I'm struggling to see how one would ever use it correctly with the
current implementation. It seems to rely on the assumption of a
never-ending stream of tightly-spaced input packets? It seems like it
was meant for usage on blocking sockets. Given a blocking socket with
timeout 0 (infinite), and a recvmmsg timeout of 100us, if you had a
very steady stream of input packets, it recvmmsg would pull in all of
them that it could within a max timeframe of (100us +
time_to_execute_one_recvmsg). However, any disruption to the input
stream for a time-window of N would result in delaying some
already-received packets by N. For example, consider the case that 2
packets are already queued when you invoke recvmmsg(), but then the
next packet doesn't arrive for another 300ms. In this scenario, you'd
end up with recvmmsg() blocking for 300ms and then returning all 3
packets, two of which have been delayed way beyond the specified
timeout.
-- Brandon
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Andi Kleen @ 2010-03-27 13:11 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andi Kleen, David Miller, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1003261231410.30253@router.home>
On Fri, Mar 26, 2010 at 12:33:07PM -0500, Christoph Lameter wrote:
> Here is a pgm.7 manpage describing how the socket API could look like for
> a PGM implementation.
>
> I dumped the RM_* based socket options from the other OS since most of the
> options were unusable.
I did a quick read and the manpage/interface seem reasonable to me.
You changed the parameter struct fields to lower case. While
that looks definitely more Linuxy than before does it mean programs
have to #ifdef this? It might be good idea to have at least some
optional compat header that #defines.
-Andi
^ permalink raw reply
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Wolfram Sang @ 2010-03-27 12:57 UTC (permalink / raw)
To: Bryan Wu
Cc: s.hauer, gerg, amit.kucheria, netdev, kernel-team, linux-kernel,
linux-arm-kernel
In-Reply-To: <1269597052-10104-1-git-send-email-bryan.wu@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On Fri, Mar 26, 2010 at 05:50:52PM +0800, Bryan Wu wrote:
> BugLink: http://bugs.launchpad.net/bugs/457878
>
> - removed old MII phy control code
> - add phylib supporting
> - add ethtool interface to make user space NetworkManager works
>
> Tested on Freescale i.MX51 Babbage board.
Sadly, I have problems here booting a custom board:
...
FEC Ethernet Driver
fec_enet_mii_bus: probed
eth0: Freescale FEC PHY driver [SMSC LAN8700] (mii_bus:phy_addr=0:1f, irq=-1)
... (That's fine, so far)
PHY: 0:1f - Link is Up - 100/Full
... (also nice)
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x2c0/0x2e0()
NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Modules linked in:
[<c001f8d4>] (unwind_backtrace+0x0/0xe4) from [<c002d1d0>] (warn_slowpath_common+0x4c/0x80)
[<c002d1d0>] (warn_slowpath_common+0x4c/0x80) from [<c002d240>] (warn_slowpath_fmt+0x28/0x38)
[<c002d240>] (warn_slowpath_fmt+0x28/0x38) from [<c01be32c>] (dev_watchdog+0x2c0/0x2e0)
[<c01be32c>] (dev_watchdog+0x2c0/0x2e0) from [<c0038740>] (run_timer_softirq+0x1c0/0x274)
[<c0038740>] (run_timer_softirq+0x1c0/0x274) from [<c0032f98>] (__do_softirq+0x8c/0x120)
[<c0032f98>] (__do_softirq+0x8c/0x120) from [<c00330b0>] (irq_exit+0x84/0xa0)
[<c00330b0>] (irq_exit+0x84/0xa0) from [<c001a040>] (asm_do_IRQ+0x40/0x8c)
[<c001a040>] (asm_do_IRQ+0x40/0x8c) from [<c001ab8c>] (__irq_svc+0x4c/0x8c)
Exception stack(0xc02c3f78 to 0xc02c3fc0)
3f60: 00000000 0005317f
3f80: 0005217f 60000013 c02c2000 c02db7ec c02c59c4 c02c59b8 a0018270 41069264
3fa0: a001823c 00000000 600000d3 c02c3fc0 c001ba8c c001ba98 60000013 ffffffff
[<c001ab8c>] (__irq_svc+0x4c/0x8c) from [<c001ba98>] (default_idle+0x2c/0x34)
[<c001ba98>] (default_idle+0x2c/0x34) from [<c001bfac>] (cpu_idle+0x90/0xc8)
[<c001bfac>] (cpu_idle+0x90/0xc8) from [<c000898c>] (start_kernel+0x234/0x2c0)
[<c000898c>] (start_kernel+0x234/0x2c0) from [<a0008034>] (0xa0008034)
---[ end trace ce1c823381bff119 ]---
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
...
I just threw the patch on top of 2.6.33.1, after picking
633e7533cec78b99d806248e832fc83e689d2453 (fec: fix uninitialized rx buffer
usage), too. Just needed to adapt the Kconfig entry, the patch for fec.c went
smooth. So, I doubt the slightly older kernel is the problem (but will check
net-next somewhen later)? Using the "old" method for the LAN8700, I get a
working eth0, so the hardware should work in general. I will have a closer look
on Monday, this was just a quick try. If you happen to have pointers where to
start, this is appreciated.
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 12:32 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <20100327122642.GA5165@electric-eye.fr.zoreil.com>
François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
>> It seems that adding single printk between writing MAC0 and MAC4 fixes it.
>> I guess it needs a bit of delay between the writes or something.
>
> Can you test with a single RTL_R32 after each MACx write ?
Adding reading back of the written value fixes it too. Though, disassembly
says that it added an extra instructions also (needs to load the 'high' from
stack before writing it) so the added delay is probably slightly more than
just the io read.
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 12:26 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADF738.2060600@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> It seems that adding single printk between writing MAC0 and MAC4 fixes it.
> I guess it needs a bit of delay between the writes or something.
Can you test with a single RTL_R32 after each MACx write ?
--
Ueimor
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 12:25 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADF738.2060600@iki.fi>
Timo Teräs wrote:
> François Romieu wrote:
>> Timo Teräs <timo.teras@iki.fi> :
>> [...]
>>> I don't think this would do anything. The high part is recorded
>>> correctly always.
>>> It's the 'low' part that gets discarded. I can do similar test if
>>> writing it
>>> more times will help. Will post results soon.
>>
>> You may check whether writing MAC4 before MAC0 makes a difference
>> or not as well.
>
> It seems that adding single printk between writing MAC0 and MAC4 fixes it.
> I guess it needs a bit of delay between the writes or something.
Oh, and writing MAC4 first seems to fix it too.
- Timo
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 12:16 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <20100327120358.GA5114@electric-eye.fr.zoreil.com>
François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
>> I don't think this would do anything. The high part is recorded correctly always.
>> It's the 'low' part that gets discarded. I can do similar test if writing it
>> more times will help. Will post results soon.
>
> You may check whether writing MAC4 before MAC0 makes a difference
> or not as well.
It seems that adding single printk between writing MAC0 and MAC4 fixes it.
I guess it needs a bit of delay between the writes or something.
^ 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