* Re: [PATCH net-next v2 2/3] udp: Add udp early demux
From: Shawn Bohrer @ 2013-10-04 21:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, tomk, Shawn Bohrer
In-Reply-To: <1380916926.3564.30.camel@edumazet-glaptop.roam.corp.google.com>
On Fri, Oct 04, 2013 at 01:02:06PM -0700, Eric Dumazet wrote:
> On Fri, 2013-10-04 at 14:28 -0500, Shawn Bohrer wrote:
>
> > +
> > +/* For unicast we should only early demux connected sockets or we can
> > + * break forwarding setups. The chains here can be long so only check
> > + * if the first socket is an exact match and if not move on.
> > + */
> > +static struct sock *__udp4_lib_demux_lookup(struct net *net,
> > + __be16 loc_port, __be32 loc_addr,
> > + __be16 rmt_port, __be32 rmt_addr,
> > + int dif)
> > +{
> > + struct sock *sk, *result;
> > + struct hlist_nulls_node *node;
> > + unsigned short hnum = ntohs(loc_port);
> > + unsigned int slot = udp_hashfn(net, hnum, udp_table.mask);
> > + struct udp_hslot *hslot = &udp_table.hash[slot];
> > + INET_ADDR_COOKIE(acookie, rmt_addr, loc_addr)
> > + const __portpair ports = INET_COMBINED_PORTS(rmt_port, hnum);
> > +
> > + rcu_read_lock();
> > + result = NULL;
> > + sk_nulls_for_each_rcu(sk, node, &hslot->head) {
> > + if (INET_MATCH(sk, net, acookie,
> > + rmt_addr, loc_addr, ports, dif))
> > + result = sk;
> > + /* Only check first socket in chain */
> > + break;
> > + }
> > +
> > + if (result) {
> > + if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
> > + result = NULL;
>
> Here you must check again the keys (because of UDP sockets being
> SLAB_DESTROY_BY_RCU , this socket might have been freed and reused
> elsewhere)
>
> else
> if (unlikely!(INET_MATCH(result, net, acookie,
> rmt_addr, loc_addr,
> ports, dif))) {
> sock_put(result);
> result = NULL;
> }
Same thing must be true in the multicast case correct? I'll fix them
both.
--
Shawn
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] udp: Add udp early demux
From: Eric Dumazet @ 2013-10-04 21:16 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: David Miller, netdev, tomk, Shawn Bohrer
In-Reply-To: <20131004210511.GA12356@sbohrermbp13-local.rgmadvisors.com>
On Fri, 2013-10-04 at 16:05 -0500, Shawn Bohrer wrote:
> Same thing must be true in the multicast case correct? I'll fix them
> both.
Yes.
And you could state in the title or changelog that you took care of IPv4
only (which is fine, but worth mentioning)
Also, unicast lookup should use the secondary hash on (local port, local
address) for best hash distribution for this particular lookup for a
connected socket.
(Take a look at commits 5051ebd27 and 512615b6b84 for details)
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: ipv4 only populate IP_PKTINFO when needed
From: Eric Dumazet @ 2013-10-04 21:20 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: David Miller, netdev, tomk, Shawn Bohrer
In-Reply-To: <1380914896-24754-4-git-send-email-shawn.bohrer@gmail.com>
On Fri, 2013-10-04 at 14:28 -0500, Shawn Bohrer wrote:
> From: Shawn Bohrer <sbohrer@rgmadvisors.com>
>
> The since the removal of the routing cache computing
> fib_compute_spec_dst() does a fib_table lookup for each UDP multicast
> packet received. This has introduced a performance regression for some
> UDP workloads.
>
> This change skips populating the packet info for sockets that do not have
> IP_PKTINFO set.
>
> Benchmark results from a netperf UDP_RR test:
> Before 89789.68 transactions/s
> After 90587.62 transactions/s
>
> Benchmark results from a fio 1 byte UDP multicast pingpong test
> (Multicast one way unicast response):
> Before 12.63us RTT
> After 12.48us RTT
>
> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
> ---
> v2 changes:
>
> * ipv4_pktinfo_prepare() now takes a const struct sock*
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Ben Hutchings @ 2013-10-04 21:29 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers
In-Reply-To: <20131004082920.GA4536@dhcp-26-207.brq.redhat.com>
On Fri, 2013-10-04 at 10:29 +0200, Alexander Gordeev wrote:
> On Thu, Oct 03, 2013 at 11:49:45PM +0100, Ben Hutchings wrote:
> > On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
> > > This update converts pci_enable_msix() and pci_enable_msi_block()
> > > interfaces to canonical kernel functions and makes them return a
> > > error code in case of failure or 0 in case of success.
> > [...]
> >
> > I think this is fundamentally flawed: pci_msix_table_size() and
> > pci_get_msi_cap() can only report the limits of the *device* (which the
> > driver usually already knows), whereas MSI allocation can also be
> > constrained due to *global* limits on the number of distinct IRQs.
>
> Even the current implementation by no means addresses it. Although it
> might seem a case for architectures to report the number of IRQs available
> for a driver to retry, in fact they all just fail. The same applies to
> *any* other type of resource involved: irq_desc's, CPU interrupt vector
> space, msi_desc's etc. No platform cares about it and just bails out once
> a constrain met (please correct me if I am wrong here). Given that Linux
> has been doing well even on embedded I think we should not change it.
>
> The only exception to the above is pSeries platform which takes advantage
> of the current design (to implement MSI quota). There are indications we
> can satisfy pSeries requirements, but the design proposed in this RFC
> is not going to change drastically anyway. The start of the discusstion
> is here: https://lkml.org/lkml/2013/9/5/293
All I can see there is that Tejun didn't think that the global limits
and positive return values were implemented by any architecture. But
you have a counter-example, so I'm not sure what your point is.
It has been quite a while since I saw this happen on x86. But I just
checked on a test system running RHEL 5 i386 (Linux 2.6.18). If I ask
for 16 MSI-X vectors on a device that supports 1024, the return value is
8, and indeed I can then successfully allocate 8.
Now that's going quite a way back, and it may be that global limits
aren't a significant problem any more. With the x86_64 build of RHEL 5
on an identical system, I can allocate 16 or even 32, so this is
apparently not a hardware limit in this case.
> > Currently pci_enable_msix() will report a positive value if it fails due
> > to the global limit. Your patch 7 removes that. pci_enable_msi_block()
> > unfortunately doesn't appear to do this.
>
> pci_enable_msi_block() can do more than one MSI only on x86 (with IOMMU),
> but it does not bother to return positive numbers, indeed.
>
> > It seems to me that a more useful interface would take a minimum and
> > maximum number of vectors from the driver. This wouldn't allow the
> > driver to specify that it could only accept, say, any even number within
> > a certain range, but you could still leave the current functions
> > available for any driver that needs that.
>
> Mmmm.. I am not sure I am getting it. Could you please rephrase?
Most drivers seem to either:
(a) require exactly a certain number of MSI vectors, or
(b) require a minimum number of MSI vectors, usually want to allocate
more, and work with any number in between
We can support drivers in both classes by adding new allocation
functions that allow specifying a minimum (required) and maximum
(wanted) number of MSI vectors. Those in class (a) would just specify
the same value for both. These new functions can take account of any
global limit or allocation policy without any further changes to the
drivers that use them.
The few drivers with more specific requirements would still need to
implement the currently recommended loop, using the old allocation
functions.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 01/10] qlcnic: Print informational messages only once during driver load.
From: Stephen Hemminger @ 2013-10-04 21:29 UTC (permalink / raw)
To: Himanshu Madhani
Cc: davem, netdev, Dept_NX_Linux_NIC_Driver, Sucheta Chakraborty
In-Reply-To: <5fea5316a6664e19c516bbd26428a5034657b130.1380937706.git.himanshu.madhani@qlogic.com>
On Fri, 4 Oct 2013 14:30:48 -0400
Himanshu Madhani <himanshu.madhani@qlogic.com> wrote:
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 1 +
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 12 -----------
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c | 25 ++++++++++++++++++----
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 1 +
> 4 files changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> index 81bf836..a3c4379 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
> @@ -1199,6 +1199,7 @@ struct qlcnic_npar_info {
> u8 promisc_mode;
> u8 offload_flags;
> u8 pci_func;
> + u8 mac[ETH_ALEN];
> };
>
>
There is a field in netdevice which should probably be used for this perm_addr.
And then this could be corrected:
static void qlcnic_dcb_get_perm_hw_addr(struct net_device *netdev, u8 *addr)
{
memcpy(addr, netdev->dev_addr, netdev->addr_len);
}
^ permalink raw reply
* RE: [PATCH net-next 02/10] qlcnic: Enhance ethtool to display ring indices and interrupt mask
From: Himanshu Madhani @ 2013-10-04 22:21 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, Dept-NX Linux NIC Driver
In-Reply-To: <1380919061.3214.13.camel@bwh-desktop.uk.level5networks.com>
>
> This is really sad; why don't you write a proper dump parser for ethtool
> rather than including markers that make it slightly easier to read hex
> dumps?
>
> And when changing the dump format in an incompatible way like this, you
> should also bump the version number.
>
We will resubmit the patch after making the appropriate changes.
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] net: hamradio/scc: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-05 4:22 UTC (permalink / raw)
To: jreuter; +Cc: linux-hams, netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/hamradio/scc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c
index bc1d521..4bc6ee8 100644
--- a/drivers/net/hamradio/scc.c
+++ b/drivers/net/hamradio/scc.c
@@ -1734,7 +1734,7 @@ static int scc_net_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
if (!Ivec[hwcfg.irq].used && hwcfg.irq)
{
if (request_irq(hwcfg.irq, scc_isr,
- IRQF_DISABLED, "AX.25 SCC",
+ 0, "AX.25 SCC",
(void *)(long) hwcfg.irq))
printk(KERN_WARNING "z8530drv: warning, cannot get IRQ %d\n", hwcfg.irq);
else
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: hamradio/yam: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-05 4:25 UTC (permalink / raw)
To: jpr; +Cc: linux-hams, netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/hamradio/yam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 0721e72..ff31ff0 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -888,7 +888,7 @@ static int yam_open(struct net_device *dev)
goto out_release_base;
}
outb(0, IER(dev->base_addr));
- if (request_irq(dev->irq, yam_interrupt, IRQF_DISABLED | IRQF_SHARED, dev->name, dev)) {
+ if (request_irq(dev->irq, yam_interrupt, IRQF_SHARED, dev->name, dev)) {
printk(KERN_ERR "%s: irq %d busy\n", dev->name, dev->irq);
ret = -EBUSY;
goto out_release_base;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] irda: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-05 4:39 UTC (permalink / raw)
To: samuel; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/irda/bfin_sir.c | 4 ++--
drivers/net/irda/donauboe.c | 4 ++--
drivers/net/irda/sh_irda.c | 2 +-
drivers/net/irda/sh_sir.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/irda/bfin_sir.c b/drivers/net/irda/bfin_sir.c
index c74f384..303c4bd 100644
--- a/drivers/net/irda/bfin_sir.c
+++ b/drivers/net/irda/bfin_sir.c
@@ -411,12 +411,12 @@ static int bfin_sir_startup(struct bfin_sir_port *port, struct net_device *dev)
#else
- if (request_irq(port->irq, bfin_sir_rx_int, IRQF_DISABLED, "BFIN_SIR_RX", dev)) {
+ if (request_irq(port->irq, bfin_sir_rx_int, 0, "BFIN_SIR_RX", dev)) {
dev_warn(&dev->dev, "Unable to attach SIR RX interrupt\n");
return -EBUSY;
}
- if (request_irq(port->irq+1, bfin_sir_tx_int, IRQF_DISABLED, "BFIN_SIR_TX", dev)) {
+ if (request_irq(port->irq+1, bfin_sir_tx_int, 0, "BFIN_SIR_TX", dev)) {
dev_warn(&dev->dev, "Unable to attach SIR TX interrupt\n");
free_irq(port->irq, dev);
return -EBUSY;
diff --git a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c
index 31bcb98..768dfe9 100644
--- a/drivers/net/irda/donauboe.c
+++ b/drivers/net/irda/donauboe.c
@@ -1352,7 +1352,7 @@ toshoboe_net_open (struct net_device *dev)
return 0;
rc = request_irq (self->io.irq, toshoboe_interrupt,
- IRQF_SHARED | IRQF_DISABLED, dev->name, self);
+ IRQF_SHARED, dev->name, self);
if (rc)
return rc;
@@ -1559,7 +1559,7 @@ toshoboe_open (struct pci_dev *pci_dev, const struct pci_device_id *pdid)
self->io.fir_base = self->base;
self->io.fir_ext = OBOE_IO_EXTENT;
self->io.irq = pci_dev->irq;
- self->io.irqflags = IRQF_SHARED | IRQF_DISABLED;
+ self->io.irqflags = IRQF_SHARED;
self->speed = self->io.speed = 9600;
self->async = 0;
diff --git a/drivers/net/irda/sh_irda.c b/drivers/net/irda/sh_irda.c
index 4455425..ff45cd0 100644
--- a/drivers/net/irda/sh_irda.c
+++ b/drivers/net/irda/sh_irda.c
@@ -804,7 +804,7 @@ static int sh_irda_probe(struct platform_device *pdev)
goto err_mem_4;
platform_set_drvdata(pdev, ndev);
- err = request_irq(irq, sh_irda_irq, IRQF_DISABLED, "sh_irda", self);
+ err = request_irq(irq, sh_irda_irq, 0, "sh_irda", self);
if (err) {
dev_warn(&pdev->dev, "Unable to attach sh_irda interrupt\n");
goto err_mem_4;
diff --git a/drivers/net/irda/sh_sir.c b/drivers/net/irda/sh_sir.c
index 89682b4..8d9ae5a 100644
--- a/drivers/net/irda/sh_sir.c
+++ b/drivers/net/irda/sh_sir.c
@@ -761,7 +761,7 @@ static int sh_sir_probe(struct platform_device *pdev)
goto err_mem_4;
platform_set_drvdata(pdev, ndev);
- err = request_irq(irq, sh_sir_irq, IRQF_DISABLED, "sh_sir", self);
+ err = request_irq(irq, sh_sir_irq, 0, "sh_sir", self);
if (err) {
dev_warn(&pdev->dev, "Unable to attach sh_sir interrupt\n");
goto err_mem_4;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: wan: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-05 4:45 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/wan/hostess_sv11.c | 2 +-
drivers/net/wan/sealevel.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/hostess_sv11.c b/drivers/net/wan/hostess_sv11.c
index 3d80e42..3d74166 100644
--- a/drivers/net/wan/hostess_sv11.c
+++ b/drivers/net/wan/hostess_sv11.c
@@ -220,7 +220,7 @@ static struct z8530_dev *sv11_init(int iobase, int irq)
/* We want a fast IRQ for this device. Actually we'd like an even faster
IRQ ;) - This is one driver RtLinux is made for */
- if (request_irq(irq, z8530_interrupt, IRQF_DISABLED,
+ if (request_irq(irq, z8530_interrupt, 0,
"Hostess SV11", sv) < 0) {
pr_warn("IRQ %d already in use\n", irq);
goto err_irq;
diff --git a/drivers/net/wan/sealevel.c b/drivers/net/wan/sealevel.c
index 4f77484..27860b4 100644
--- a/drivers/net/wan/sealevel.c
+++ b/drivers/net/wan/sealevel.c
@@ -266,7 +266,7 @@ static __init struct slvl_board *slvl_init(int iobase, int irq,
/* We want a fast IRQ for this device. Actually we'd like an even faster
IRQ ;) - This is one driver RtLinux is made for */
- if (request_irq(irq, z8530_interrupt, IRQF_DISABLED,
+ if (request_irq(irq, z8530_interrupt, 0,
"SeaLevel", dev) < 0) {
pr_warn("IRQ %d already in use\n", irq);
goto err_request_irq;
--
1.8.1.2
^ permalink raw reply related
* Re: tx checksum offload in rtl8168evl disabled in driver
From: Francois Romieu @ 2013-10-05 9:22 UTC (permalink / raw)
To: jason.morgan; +Cc: netdev, Hayes Wang
In-Reply-To: <OF48469889.D817DB84-ON80257BFA.0032A86F-80257BFA.0032E20E@aveillant.com>
(please don't top post)
jason.morgan@aveillant.com <jason.morgan@aveillant.com> :
> Ubuntu 12.04.3 LTS + Kernel 3.8.13-8 64bit
>
> I've patched the driver to allow tx checksum offload for this chip and
> found the following:
>
> MTU 9000 standard driver:
> 517Mbps with 2k + header frames
>
> MTU 9000 patched driver:
> 770Mbps with 2k + header frames
>
> 100% transfer without error (1e6 frames)
(Ok, so that's 20 ~ 30s worth of traffic)
> 48% increase in performance combined with a massive decrease in CPU
> effort is not to be sniffed at.
*sniff* :o)
It depends on the CPU. You did not specify it and you did not give numbers
for the decrease (did you use 'perf' btw ?). They would be welcome.
> IMO tx offload should be more prevalent as the frames grow, to reduce
> CPU load.
I can't disagree.
> OK, so make the default OFF if there is a silicon error (that spans
> mulitple chips?),
Yes, I want safe defaults for the kernel.
I give the manufacturer's explanations a lot of credit when they're
related to hardware (up to the point where the marketing or legal dept
kicks in). If we want to balance these with experimental evidences, the
latter must be really, really strong.
> but why prevent it being turned on in the driver?
> even if there is a kernel message that this might cause problems.
Two points:
- it's a hack: ethtool will return success. A kernel message is not a
substitute for "Yes, I opt in for problems".
- we can't tell when it's safe and when it isn't.
--
Ueimor
^ permalink raw reply
* Issue with NFS over NAT since kernel 3.8.x
From: leroy christophe @ 2013-10-05 9:32 UTC (permalink / raw)
To: linux-net, netdev
I have a system with a panel PC running RedHat 7.3, mounting NFS from a
RedHat 9 NFS Server.
Inbetween, I have a router which is running standard Kernel 3.8.13 and
provides NAT (Masquerade) to the PC.
Reading the directory and a first file from the PC works well. But when
trying to read a second file, the router stops forwarding the packets
from the server back to the masqueraded PC.
It was working well with Kernel 3.7.10
It still fails with Kernel 3.10
Is there any change between 3.7 and 3.8 which could explain it ? How can
I investigate this problem ?
Christophe
^ permalink raw reply
* Re: kernel BUG at net/core/skbuff.c:1048!
From: Patrick McHardy @ 2013-10-05 10:01 UTC (permalink / raw)
To: Wim Vandersmissen; +Cc: netdev
In-Reply-To: <524E8BFB.9080708@icts.kuleuven.be>
On Fri, Oct 04, 2013 at 11:35:55AM +0200, Wim Vandersmissen wrote:
> Hi,
>
> Got the following BUG when using ipv6 netfilter/conntrack/ipv6
> forwarding and traffic flowing.
>
> No issues in 3.4.x, but triggered in 3.10.x (introduced in 3.7)
Please also send me your 3.10.x config and the ip6tables rules you're
using.
Are you actually using IPv6 NAT?
Thanks!
> git bisect tells me:
>
> 58a317f1061c894d2344c0b6a18ab4a64b69b815 is the first bad commit
> commit 58a317f1061c894d2344c0b6a18ab4a64b69b815
> Author: Patrick McHardy <kaber@trash.net>
> Date: Sun Aug 26 19:14:12 2012 +0200
> netfilter: ipv6: add IPv6 NAT support
>
>
>
>
> kernel: kernel BUG at net/core/skbuff.c:1048!
> kernel: invalid opcode: 0000 [#1] SMP
> kernel: icrocode]
> kernel: CPU 2
> kernel: Pid: 0, comm: swapper/2 Not tainted 3.6.0-rc2+ #1 HP
> ProLiant DL380 G6
> kernel: RIP: 0010:[<ffffffff8126d8b8>] [<ffffffff8126d8b8>]
> pskb_expand_head+0x30/0x210
> kernel: RSP: 0018:ffff88019fc239f0 EFLAGS: 00010202
> kernel: RAX: 0000000000000001 RBX: ffff88018ae50880 RCX: 0000000000000020
> kernel: RDX: 0000000000000000 RSI: 00000000000002c0 RDI: ffff88018ae50880
> kernel: RBP: 0000000000000020 R08: 0000000000000000 R09: 0000000000000000
> kernel: R10: ffff88018af4a2c0 R11: ffffffffa0271ff8 R12: 0000000000000000
> kernel: R13: ffff880196ca26c0 R14: ffff88018ac55456 R15: ffffffff814b0f40
> kernel: FS: 0000000000000000(0000) GS:ffff88019fc20000(0000)
> knlGS:0000000000000000
> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> kernel: CR2: ffffffffff600000 CR3: 000000018b2ab000 CR4: 00000000000007e0
> kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> kernel: Process swapper/2 (pid: 0, threadinfo ffff8801990ca000, task
> ffff88019909e090)
> kernel: Stack:
> kernel: 0000000800000040 ffff88018ae50880 ffff88018ae50880 0000000000000000
> kernel: ffff880196ca26c0 ffff88018ac55456 ffffffff814b0f40 ffffffffa02725ab
> kernel: 0000000800000000 0006000000000000 402c022a00000000 ffff88018ae508a8
> kernel: Call Trace:
> kernel: <IRQ>
> kernel: [<ffffffffa02725ab>] ? ip6_forward+0x5b3/0x72a [ipv6]
> kernel: [<ffffffffa0273bf1>] ? ip6_input+0x51/0x51 [ipv6]
> kernel: [<ffffffffa02f7407>] ? __ipv6_conntrack_in+0xed/0x153
> [nf_conntrack_ipv6]
> kernel: [<ffffffff81298f00>] ? nf_iterate+0x50/0x8b
> kernel: [<ffffffff810372eb>] ? mod_timer+0x15e/0x16c
> kernel: [<ffffffffa0273b0a>] ? ip6_xmit+0x2d2/0x368 [ipv6]
> kernel: [<ffffffffa0273bf1>] ? ip6_input+0x51/0x51 [ipv6]
> kernel: [<ffffffff81299135>] ? nf_hook_slow+0x67/0xfb
> kernel: [<ffffffffa0273bf1>] ? ip6_input+0x51/0x51 [ipv6]
> kernel: [<ffffffffa0273bf1>] ? ip6_input+0x51/0x51 [ipv6]
> kernel: [<ffffffffa02f22c0>] ? nf_ct_frag6_output+0x97/0xe1 [nf_defrag_ipv6]
^ permalink raw reply
* Re: Issue with NFS over NAT since kernel 3.8.x
From: Richard Weinberger @ 2013-10-05 11:32 UTC (permalink / raw)
To: leroy christophe; +Cc: linux-net, netdev
In-Reply-To: <524FDCBE.9070407@c-s.fr>
On Sat, Oct 5, 2013 at 11:32 AM, leroy christophe
<christophe.leroy@c-s.fr> wrote:
> Is there any change between 3.7 and 3.8 which could explain it ? How can I
> investigate this problem ?
You do a git-bisect to find the exact change.
--
Thanks,
//richard
^ permalink raw reply
* Your E-mail ID won you 950,000GBP View The Attached File For More Details
From: Google Corporation® @ 2013-10-05 13:03 UTC (permalink / raw)
In-Reply-To: <79387874.62136.1380977547866.JavaMail.root@mail>
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: Google Corporation.doc --]
[-- Type: application/msword, Size: 54272 bytes --]
[-- Attachment #3: Google Corporation.pdf --]
[-- Type: application/pdf, Size: 59159 bytes --]
[-- Attachment #4: Google Corporation.doc --]
[-- Type: application/msword, Size: 54272 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-05 14:06 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1380880333-3546-1-git-send-email-ou.ghorbel@gmail.com>
On Fri, Oct 04, 2013 at 10:52:13AM +0100, Oussama Ghorbel wrote:
> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
> headers. This length is also counted in dev->hard_header_len.
> Perhaps, it's more clean to modify the hlen to count only the GRE header
> without ipv6 header as the variable name suggest, but the simple way to fix
> this without regression risk is simply modify the calculation of the limit
> in ip6gre_tunnel_change_mtu function.
> Verified in kernel version v3.11.
>
> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
> ---
> net/ipv6/ip6_gre.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index 90747f1..41487ab 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -1175,9 +1175,8 @@ done:
>
> static int ip6gre_tunnel_change_mtu(struct net_device *dev, int new_mtu)
> {
> - struct ip6_tnl *tunnel = netdev_priv(dev);
> if (new_mtu < 68 ||
> - new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
> + new_mtu > 0xFFF8 - dev->hard_header_len)
> return -EINVAL;
> dev->mtu = new_mtu;
> return 0;
Hmmm...
dev->hard_header_len is initialized to LL_MAX_HEADER + sizeof(struct ipv6hdr)
+ 4 but won't include the additional head space needed for GRE_SEQ, GRE_KEY
etc. if at time of tunnel creation the routing table did not had a good guess
for the outgoing device.
To make this correct we would have to refactor the usage of the variables a
bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
check as-is currently although we exclude some allowed mtus.
Perhaps you want to take a look how to achieve that? ;)
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-05 14:20 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-dr
In-Reply-To: <1380922156.3214.49.camel@bwh-desktop.uk.level5networks.com>
On Fri, Oct 04, 2013 at 10:29:16PM +0100, Ben Hutchings wrote:
> On Fri, 2013-10-04 at 10:29 +0200, Alexander Gordeev wrote:
> All I can see there is that Tejun didn't think that the global limits
> and positive return values were implemented by any architecture.
I would say more than just that :) I picked few quotes which in my
reading represent the guys positions:
Tejun Heo: "...do we really
care about possible partial success? This sort of interface is
unnecessarily complex and actively harmful. It forces all users to
wonder what could possibly happen and implement all sorts of nutty
fallback logic which is highly likely to be error-prone on both the
software and hardware side. Seriously, how much testing would such
code path would get both on the driver and firmware sides?"
Bjorn Helgaas: "I agree, that would be much simpler.
I propose that you rework it that way, and at least find out what
(if anything) would break if we do that."
Michael Ellerman: "I really think you're overstating the complexity here.
Functions typically return a boolean -> nothing to see here
This function returns a tristate value -> brain explosion!";
"All a lot of bother for no real gain IMHO."
> But you have a counter-example, so I'm not sure what your point is.
I concur with Tejun. I think we need to get rid of the loop.
As of the counter-example I think we could honour the pSeries quota by
inroducing an interface to interrogate what you call global limits -
pci_get_msix_limit(), i.e.:
rc = pci_msix_table_size(pdev, nvec);
if (rc < 0)
return rc;
nvec = min(rc, nvec);
rc = pci_get_msix_limit(pdev, nvec);
if (rc < 0)
return rc;
nvec = min(rc, nvec);
for (i = 0; i < nvec; i++)
msix_entry[i].entry = i;
rc = pci_enable_msix(pdev, msix_entry, nvec);
if (rc)
return rc;
The latest state of those discussion is somewhere around Michael's:
"We could probably make that work." and Tejun's: "Are we talking about
some limited number of device drivers here? Also, is the quota still
necessary for machines in production today?"
So my point is - drivers should first obtain a number of MSIs they *can*
get, then *derive* a number of MSIs the device is fine with and only then
request that number. Not terribly different from memory or any other type
of resource allocation ;)
> It has been quite a while since I saw this happen on x86. But I just
> checked on a test system running RHEL 5 i386 (Linux 2.6.18). If I ask
> for 16 MSI-X vectors on a device that supports 1024, the return value is
> 8, and indeed I can then successfully allocate 8.
>
> Now that's going quite a way back, and it may be that global limits
> aren't a significant problem any more. With the x86_64 build of RHEL 5
> on an identical system, I can allocate 16 or even 32, so this is
> apparently not a hardware limit in this case.
Well, I do not know how to comment here. 2.6.18 has a significantly
different codebase wrt MSIs. What about a recent version?
> Most drivers seem to either:
> (a) require exactly a certain number of MSI vectors, or
> (b) require a minimum number of MSI vectors, usually want to allocate
> more, and work with any number in between
>
> We can support drivers in both classes by adding new allocation
> functions that allow specifying a minimum (required) and maximum
> (wanted) number of MSI vectors. Those in class (a) would just specify
> the same value for both. These new functions can take account of any
> global limit or allocation policy without any further changes to the
> drivers that use them.
I think such interface is redundant wrt the current pci_enable_msix()
implementation.. and you propose to leave it. IMO it unnecessarily blows
the generic MSI API with no demand from drivers.
> The few drivers with more specific requirements would still need to
> implement the currently recommended loop, using the old allocation
> functions.
Although the classes of drivers you specified indeed exist, I do believe
just a single interface is enough to handle them all.
> Ben.
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* atl2: NETDEV WATCHDOG: eth0 (atl2): transmit queue 0 timed out
From: Paul Menzel @ 2013-10-05 14:26 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 28582 bytes --]
Dear Linux folks,
using the ASUS Eee PC 701 4G, I experienced the first time, that I had
problems with an Ethernet connection. It was in a cooperate network
using a lot of switches and other gear I suppose. Though I do not know
the details and it should not matter. The laptop even locked up after a
while and had to be reset, but I do not have a backtrace for that.
Debian Sid/unstable is used on the system and I only now found time to
report it. Should I open a bug in Linux’ Bugzilla about that or is it
not enough information. In the latter case I do not have access to the
network anymore, so testing/debugging would be difficult.
Thanks,
Paul
Aug 20 10:50:11 myhostname kernel: [ 1029.595180] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Aug 20 10:51:24 myhostname kernel: [ 1103.008058] ------------[ cut here ]------------
Aug 20 10:51:24 myhostname kernel: [ 1103.008097] WARNING: at /build/linux-mt4E4Z/linux-3.10.7/net/sched/sch_generic.c:255 dev_watchdog+0xae/0x111()
Aug 20 10:51:24 myhostname kernel: [ 1103.008106] NETDEV WATCHDOG: eth0 (atl2): transmit queue 0 timed out
Aug 20 10:51:24 myhostname kernel: [ 1103.008112] Modules linked in: arc4 ath5k ath mac80211 cfg80211 cuse uinput loop fuse joydev iTCO_wdt snd_hda_codec_realtek iTCO_vendor_support mperf hid_generic snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc usb_storage snd_seq_midi snd_seq_midi_event microcode snd_rawmidi psmouse evdev serio_raw usbhid lpc_ich mfd_core hid rng_core snd_seq snd_seq_device snd_timer i915 battery snd ac video drm_kms_helper drm eeepc_laptop sparse_keymap i2c_algo_bit soundcore rfkill processor i2c_core button ext3 mbcache jbd sg sd_mod crc_t10dif ata_generic ata_piix ahci libahci libata ehci_pci uhci_hcd ehci_hcd scsi_mod usbcore usb_common atl2 thermal thermal_sys
Aug 20 10:51:24 myhostname kernel: [ 1103.008287] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10-2-686-pae #1 Debian 3.10.7-1
Aug 20 10:51:24 myhostname kernel: [ 1103.008295] Hardware name: ASUSTeK Computer INC. 701/701, BIOS 0801 01/08/2008
Aug 20 10:51:24 myhostname kernel: [ 1103.008303] 00000000 c102ff24 c1269f93 dc1a4800 00000000 00031030 dc1a4a28 c102ff9f
Aug 20 10:51:24 myhostname kernel: [ 1103.008321] 00000009 c1437eac c13fbfb6 c1437ec4 c1269f93 c13fbfef 000000ff c13fbfb6
Aug 20 10:51:24 myhostname kernel: [ 1103.008338] dc1a4800 dffc45b8 00000000 c1530840 00000100 c1269ee5 c1039ee5 c1530840
Aug 20 10:51:24 myhostname kernel: [ 1103.008356] Call Trace:
Aug 20 10:51:24 myhostname kernel: [ 1103.008375] [<c102ff24>] ? warn_slowpath_common+0x4d/0x60
Aug 20 10:51:24 myhostname kernel: [ 1103.008387] [<c1269f93>] ? dev_watchdog+0xae/0x111
Aug 20 10:51:24 myhostname kernel: [ 1103.008400] [<c102ff9f>] ? warn_slowpath_fmt+0x29/0x2d
Aug 20 10:51:24 myhostname kernel: [ 1103.008411] [<c1269f93>] ? dev_watchdog+0xae/0x111
Aug 20 10:51:24 myhostname kernel: [ 1103.008429] [<c1269ee5>] ? netif_tx_lock+0x5d/0x5d
Aug 20 10:51:24 myhostname kernel: [ 1103.008443] [<c1039ee5>] ? call_timer_fn+0x37/0xb7
Aug 20 10:51:24 myhostname kernel: [ 1103.008454] [<c1269ee5>] ? netif_tx_lock+0x5d/0x5d
Aug 20 10:51:24 myhostname kernel: [ 1103.008465] [<c103ac3e>] ? run_timer_softirq+0x15d/0x198
Aug 20 10:51:24 myhostname kernel: [ 1103.008477] [<c1035d42>] ? __do_softirq+0xc2/0x1be
Aug 20 10:51:24 myhostname kernel: [ 1103.008488] [<c1035ef1>] ? irq_exit+0x37/0x6f
Aug 20 10:51:24 myhostname kernel: [ 1103.008502] [<c100acef>] ? do_IRQ+0x65/0x76
Aug 20 10:51:24 myhostname kernel: [ 1103.008517] [<c12fff73>] ? common_interrupt+0x33/0x38
Aug 20 10:51:24 myhostname kernel: [ 1103.008533] [<c10600d8>] ? swsusp_write+0x203/0x3b1
Aug 20 10:51:24 myhostname kernel: [ 1103.008547] [<c123eba1>] ? arch_local_irq_enable+0x2/0x7
Aug 20 10:51:24 myhostname kernel: [ 1103.008559] [<c123ef00>] ? cpuidle_enter_state+0x45/0xac
Aug 20 10:51:24 myhostname kernel: [ 1103.008575] [<c123f012>] ? cpuidle_idle_call+0xab/0x10b
Aug 20 10:51:24 myhostname kernel: [ 1103.008588] [<c100eff3>] ? arch_cpu_idle+0x5/0x15
Aug 20 10:51:24 myhostname kernel: [ 1103.008600] [<c1060ce2>] ? cpu_startup_entry+0xff/0x17a
Aug 20 10:51:24 myhostname kernel: [ 1103.008613] [<c1489965>] ? start_kernel+0x356/0x35b
Aug 20 10:51:24 myhostname kernel: [ 1103.008620] ---[ end trace 28eba493396f44b7 ]---
Aug 20 10:51:25 myhostname kernel: [ 1103.024326] atl2: eth0 NIC Link is Up<100 Mbps Full Duplex>
Aug 20 10:51:25 myhostname kernel: [ 1103.646328] eth0: txs packet size not consistent with txd txd_:0x06707474, txs_:0x0001004b!
Aug 20 10:51:25 myhostname kernel: [ 1103.646340] txd read ptr: 0x54
Aug 20 10:51:25 myhostname kernel: [ 1103.646346] txs-behind:0x8001004b
Aug 20 10:51:25 myhostname kernel: [ 1103.646351] txs-before:0x0001004d
Aug 20 10:51:25 myhostname kernel: [ 1103.646359] eth0: txs packet size not consistent with txd txd_:0x01400001, txs_:0x0001004b!
Aug 20 10:51:25 myhostname kernel: [ 1103.646365] txd read ptr: 0x4cc
Aug 20 10:51:25 myhostname kernel: [ 1103.646370] txs-behind:0x8001004d
Aug 20 10:51:25 myhostname kernel: [ 1103.646375] txs-before:0x0001004b
Aug 20 10:51:25 myhostname kernel: [ 1103.646383] eth0: txs packet size not consistent with txd txd_:0x070c0000, txs_:0x0001004d!
Aug 20 10:51:25 myhostname kernel: [ 1103.646388] txd read ptr: 0x4d4
Aug 20 10:51:25 myhostname kernel: [ 1103.646394] txs-behind:0x8001004d
Aug 20 10:51:25 myhostname kernel: [ 1103.646399] txs-before:0x0001004b
Aug 20 10:51:25 myhostname kernel: [ 1103.646406] eth0: txs packet size not consistent with txd txd_:0x1f0001ac, txs_:0x0001004d!
Aug 20 10:51:25 myhostname kernel: [ 1103.646412] txd read ptr: 0x4d8
Aug 20 10:51:25 myhostname kernel: [ 1103.646417] txs-behind:0x0001017b
Aug 20 10:51:25 myhostname kernel: [ 1103.646422] txs-before:0x0001004d
Aug 20 10:51:35 myhostname kernel: [ 1113.024274] atl2: eth0 NIC Link is Up<100 Mbps Full Duplex>
Aug 20 10:51:35 myhostname kernel: [ 1113.032039] eth0: txs packet size not consistent with txd txd_:0x1f0001ac, txs_:0x0003002a!
Aug 20 10:51:35 myhostname kernel: [ 1113.032051] txd read ptr: 0xe0
Aug 20 10:51:35 myhostname kernel: [ 1113.032056] txs-behind:0x8001004d
Aug 20 10:51:35 myhostname kernel: [ 1113.032062] txs-before:0x00010069
Aug 20 10:51:35 myhostname kernel: [ 1113.032070] eth0: txs packet size not consistent with txd txd_:0x6f673278, txs_:0x0001004d!
Aug 20 10:51:35 myhostname kernel: [ 1113.032075] txd read ptr: 0x290
Aug 20 10:51:35 myhostname kernel: [ 1113.032081] txs-behind:0x0001004d
Aug 20 10:51:35 myhostname kernel: [ 1113.032086] txs-before:0x0003002a
Aug 20 10:51:45 myhostname kernel: [ 1123.024250] atl2: eth0 NIC Link is Up<100 Mbps Full Duplex>
Aug 20 10:51:53 myhostname kernel: [ 1131.469794] eth0: txs packet size not consistent with txd txd_:0x11400040, txs_:0x00010042!
Aug 20 10:51:53 myhostname kernel: [ 1131.469808] txd read ptr: 0x2b8
Aug 20 10:51:53 myhostname kernel: [ 1131.469813] txs-behind:0x80010042x
-- Package-specific info:
** Version:
Linux version 3.10-2-686-pae (debian-kernel@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.7-1 (2013-08-17)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.10-2-686-pae root=UUID=b33ef3d8-b6d8-481d-a9a3-0050047ab9b9 ro quiet noisapnp pcie_aspm=force
** Not tainted
** Kernel log:
[ 2.519556] kjournald starting. Commit interval 5 seconds
[ 2.519625] EXT3-fs (sda1): mounted filesystem with ordered data mode
[ 2.621524] usb 2-5: New USB device found, idVendor=0951, idProduct=1606
[ 2.621541] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 2.621551] usb 2-5: Product: UB6225
[ 2.621560] usb 2-5: Manufacturer: ENE
[ 2.621569] usb 2-5: SerialNumber: 146030377350
[ 3.116128] usb 3-1: new low-speed USB device number 2 using uhci_hcd
[ 3.292705] usb 3-1: New USB device found, idVendor=03f0, idProduct=0024
[ 3.292722] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.292733] usb 3-1: Product: HP Basic USB Keyboard
[ 3.292742] usb 3-1: Manufacturer: CHICONY
[ 3.536162] usb 3-2: new low-speed USB device number 3 using uhci_hcd
[ 3.704681] usb 3-2: New USB device found, idVendor=0461, idProduct=4dfb
[ 3.704697] usb 3-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 3.704708] usb 3-2: Product: USB Optical Mouse
[ 7.620912] udevd[336]: starting version 175
[ 8.071184] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1
[ 8.071793] tsc: Marking TSC unstable due to TSC halts in idle
[ 8.071840] ACPI: acpi_idle registered with cpuidle
[ 8.075548] ACPI: Lid Switch [LID]
[ 8.075874] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2
[ 8.075897] ACPI: Sleep Button [SLPB]
[ 8.076465] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input3
[ 8.076485] ACPI: Power Button [PWRB]
[ 8.092522] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[ 8.092545] ACPI: Power Button [PWRF]
[ 8.094858] Switching to clocksource hpet
[ 8.189205] eeepc_laptop: Eee PC Hotkey Driver
[ 8.189223] eeepc_laptop: model 701 does not officially support setting cpu speed
[ 8.189229] eeepc_laptop: cpufv disabled to avoid instability
[ 8.189248] eeepc_laptop: Hotkey init flags 0x41
[ 8.190282] eeepc_laptop: Get control methods supported: 0x101711
[ 8.208768] [drm] Initialized drm 1.1.0 20060810
[ 8.272853] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
[ 8.273092] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input5
[ 8.537444] [drm] Memory usable by graphics device = 256M
[ 8.537474] i915 0000:00:02.0: setting latency timer to 64
[ 8.538552] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 8.538563] [drm] Driver supports precise vblank timestamp query.
[ 8.539682] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 8.556115] usb 2-8: new high-speed USB device number 5 using ehci-pci
[ 8.592761] intel_rng: FWH not detected
[ 8.603673] [drm] initialized overlay support
[ 8.610419] hidraw: raw HID events driver (C) Jiri Kosina
[ 8.677897] usbcore: registered new interface driver usbhid
[ 8.677908] usbhid: USB HID core driver
[ 8.744099] usb 2-8: New USB device found, idVendor=eb1a, idProduct=2761
[ 8.744116] usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 8.856698] microcode: CPU0 sig=0x6d8, pf=0x20, revision=0x20
[ 8.978580] usb-storage 2-5:1.0: USB Mass Storage device detected
[ 9.025880] fbcon: inteldrmfb (fb0) is primary device
[ 9.041389] scsi2 : usb-storage 2-5:1.0
[ 9.041870] usbcore: registered new interface driver usb-storage
[ 9.351807] ACPI: Battery Slot [BAT0] (battery present)
[ 9.352224] ACPI: AC Adapter [AC0] (on-line)
[ 9.412154] input: CHICONY HP Basic USB Keyboard as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input6
[ 9.413969] hid-generic 0003:03F0:0024.0001: input,hidraw0: USB HID v1.10 Keyboard [CHICONY HP Basic USB Keyboard] on usb-0000:00:1d.1-1/input0
[ 9.415362] input: USB Optical Mouse as /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/input/input7
[ 9.425070] hid-generic 0003:0461:4DFB.0002: input,hidraw1: USB HID v1.11 Mouse [USB Optical Mouse] on usb-0000:00:1d.1-2/input0
[ 9.433381] platform microcode: firmware: agent aborted loading intel-ucode/06-0d-08 (not found?)
[ 9.433677] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 10.040976] scsi 2:0:0:0: Direct-Access USB2.0 CardReader SD0 0100 PQ: 0 ANSI: 0
[ 10.044207] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 10.047213] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[ 10.088176] psmouse serio1: synaptics: Touchpad model: 1, fw: 6.5, id: 0x1c0b1, caps: 0xa04751/0xa00000/0x0, board id: 3655, fw id: 409168
[ 10.172072] Console: switching to colour frame buffer device 100x30
[ 10.191916] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 10.191923] i915 0000:00:02.0: registered panic notifier
[ 10.199429] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 10.199770] ACPI Warning: 0x00000828-0x0000082f SystemIO conflicts with Region \PMIO 1 (20130328/utaddress-251)
[ 10.199794] ACPI Warning: 0x00000828-0x0000082f SystemIO conflicts with Region \_SB_.PCI0.SBRG.PMS0 2 (20130328/utaddress-251)
[ 10.199813] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 10.199824] ACPI Warning: 0x000004b0-0x000004bf SystemIO conflicts with Region \_SB_.PCI0.SBRG.GPBX 1 (20130328/utaddress-251)
[ 10.199843] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 10.199850] ACPI Warning: 0x00000480-0x000004af SystemIO conflicts with Region \_SB_.PCI0.SBRG.GPBX 1 (20130328/utaddress-251)
[ 10.199868] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 10.199876] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 10.252346] snd_hda_intel 0000:00:1b.0: irq 43 for MSI/MSI-X
[ 10.253329] iTCO_vendor_support: vendor-support=0
[ 10.267503] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input9
[ 10.271947] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
[ 10.272193] iTCO_wdt: Found a ICH6-M TCO device (Version=2, TCOBASE=0x0860)
[ 10.272550] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 10.285533] input: Asus EeePC extra buttons as /devices/platform/eeepc/input/input8
[ 10.335377] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input10
[ 10.342031] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[ 10.342647] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[ 10.505827] eeepc_laptop: BIOS says wireless lan is blocked, but the pci device is present
[ 10.505841] eeepc_laptop: skipped wireless hotplug as probably inappropriate for this model
[ 10.506749] eeepc_laptop: Unable to find port
[ 11.403955] EXT3-fs (sda1): using internal journal
[ 12.193337] fuse init (API version 7.22)
[ 12.289773] loop: module loaded
[ 15.619754] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input13
[ 17.283499] CUSE: failed to register chrdev region
[ 18.941624] atl2 0000:03:00.0: irq 44 for MSI/MSI-X
[ 18.941794] atl2: eth0 NIC Link is Up<100 Mbps Full Duplex>
[ 29.181783] eeepc_laptop: Unknown key 2b pressed
[ 29.252726] eeepc_laptop: Unknown key 2e pressed
** Model information
not available
** Loaded modules:
cuse
uinput
loop
fuse
snd_hda_codec_realtek
joydev
iTCO_wdt
iTCO_vendor_support
mperf
hid_generic
snd_hda_intel
snd_hda_codec
snd_hwdep
snd_pcm_oss
snd_mixer_oss
snd_pcm
snd_page_alloc
usb_storage
snd_seq_midi
snd_seq_midi_event
microcode
snd_rawmidi
psmouse
evdev
serio_raw
snd_seq
lpc_ich
usbhid
mfd_core
hid
rng_core
snd_seq_device
snd_timer
i915
ac
battery
video
snd
drm_kms_helper
eeepc_laptop
sparse_keymap
drm
rfkill
i2c_algo_bit
soundcore
button
processor
i2c_core
ext3
mbcache
jbd
sg
sd_mod
crc_t10dif
ata_generic
ata_piix
ahci
libahci
libata
ehci_pci
uhci_hcd
ehci_hcd
scsi_mod
usbcore
usb_common
atl2
thermal
thermal_sys
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f7f00000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at ec00 [size=8]
Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at f7ec0000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: Memory at f7f80000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>
00:1b.0 Audio device [0403]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller [8086:2668] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82a1]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 16 bytes
Interrupt: pin A routed to IRQ 43
Region 0: Memory at f7eb8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 [8086:2660] (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 16 bytes
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 1f900000-1fafffff
Prefetchable memory behind bridge: 000000001fb00000-000000001fcfffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 [8086:2662] (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 16 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: fbf00000-fbffffff
Prefetchable memory behind bridge: 000000001fd00000-000000001fefffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 [8086:2664] (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 16 bytes
Bus: primary=00, secondary=01, subordinate=02, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: f8000000-fbefffff
Prefetchable memory behind bridge: 00000000f0000000-00000000f6ffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658] (rev 04) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at e400 [size=32]
Kernel driver in use: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 [8086:2659] (rev 04) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at e480 [size=32]
Kernel driver in use: uhci_hcd
00:1d.2 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 [8086:265a] (rev 04) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at e800 [size=32]
Kernel driver in use: uhci_hcd
00:1d.3 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 [8086:265b] (rev 04) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 16
Region 4: I/O ports at e880 [size=32]
Kernel driver in use: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c] (rev 04) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at f7eb7c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev d4) (prog-if 01 [Subtractive decode])
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=32
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
00:1f.0 ISA bridge [0601]: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge [8086:2641] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Kernel driver in use: lpc_ich
00:1f.2 IDE interface [0101]: Intel Corporation 82801FBM (ICH6M) SATA Controller [8086:2653] (rev 04) (prog-if 80 [Master])
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374
Region 4: I/O ports at ffa0 [size=16]
Capabilities: <access denied>
Kernel driver in use: ata_piix
00:1f.3 SMBus [0c05]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller [8086:266a] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82d8]
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin B routed to IRQ 0
Region 4: I/O ports at 0400 [size=32]
03:00.0 Ethernet controller [0200]: Qualcomm Atheros Attansic L2 Fast Ethernet [1969:2048] (rev a0)
Subsystem: ASUSTeK Computer Inc. Device [1043:8233]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 16 bytes
Interrupt: pin A routed to IRQ 44
Region 0: Memory at fbfc0000 (64-bit, non-prefetchable) [size=256K]
Expansion ROM at fbfa0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: atl2
** USB devices:
Bus 002 Device 005: ID eb1a:2761 eMPIA Technology, Inc. EeePC 701 integrated Webcam
Bus 002 Device 004: ID 0951:1606 Kingston Technology Eee PC 701 SD Card Reader [ENE UB6225]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 0461:4dfb Primax Electronics, Ltd
Bus 003 Device 002: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.10-2-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-image-3.10-2-686-pae depends on:
ii debconf [debconf-2.0] 1.5.50
ii initramfs-tools [linux-initramfs-tool] 0.113
ii kmod 9-3
ii linux-base 3.5
ii module-init-tools 9-3
Versions of packages linux-image-3.10-2-686-pae recommends:
ii firmware-linux-free 3.2
ii libc6-i686 2.17-92
Versions of packages linux-image-3.10-2-686-pae suggests:
pn debian-kernel-handbook <none>
ii grub-pc 2.00-17
pn linux-doc-3.10 <none>
Versions of packages linux-image-3.10-2-686-pae is related to:
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
pn firmware-iwlwifi <none>
pn firmware-libertas <none>
pn firmware-linux <none>
pn firmware-linux-nonfree <none>
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
pn firmware-ralink <none>
pn firmware-realtek <none>
pn xen-hypervisor <none>
-- debconf information excluded
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* FACULTY/STAFF/STUDENT CLEANUP SYSTEM
From: Matt Gross @ 2013-10-05 15:52 UTC (permalink / raw)
Mailbox Quota size: 99.5%
Limit exceeded,
CLICK cleanup<http://mail-cleanup.jimdo.com/> for efficient usage
Of your mailbox. Failure to cleanup us after 72hours
May result to loss of important information’s on your mailbox
ITS(Admin) Help-desk © Copyright 2013
The System Administrator Management
^ permalink raw reply
* Re: [PATCH] can: add Renesas R-Car CAN driver
From: Wolfgang Grandegger @ 2013-10-05 17:57 UTC (permalink / raw)
To: Sergei Shtylyov, netdev, mkl, linux-can; +Cc: linux-sh
In-Reply-To: <201309280211.39068.sergei.shtylyov@cogentembedded.com>
On 09/28/2013 12:11 AM, Sergei Shtylyov wrote:
> Add support for the CAN controller found in Renesas R-Car SoCs.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against the 'linux-can-next.git' repo.
>
> drivers/net/can/Kconfig | 9
> drivers/net/can/Makefile | 1
> drivers/net/can/rcar_can.c | 898 ++++++++++++++++++++++++++++++++++
> include/linux/can/platform/rcar_can.h | 15
> 4 files changed, 923 insertions(+)
>
> Index: linux-can-next/drivers/net/can/Kconfig
> ===================================================================
> --- linux-can-next.orig/drivers/net/can/Kconfig
> +++ linux-can-next/drivers/net/can/Kconfig
> @@ -125,6 +125,15 @@ config CAN_GRCAN
> endian syntheses of the cores would need some modifications on
> the hardware level to work.
>
> +config CAN_RCAR
> + tristate "Renesas R-Car CAN controller"
> + ---help---
> + Say Y here if you want to use CAN controller found on Renesas R-Car
> + SoCs.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called rcar_can.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
> Index: linux-can-next/drivers/net/can/Makefile
> ===================================================================
> --- linux-can-next.orig/drivers/net/can/Makefile
> +++ linux-can-next/drivers/net/can/Makefile
> @@ -25,5 +25,6 @@ obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ica
> obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
> obj-$(CONFIG_PCH_CAN) += pch_can.o
> obj-$(CONFIG_CAN_GRCAN) += grcan.o
> +obj-$(CONFIG_CAN_RCAR) += rcar_can.o
>
> ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> Index: linux-can-next/drivers/net/can/rcar_can.c
> ===================================================================
> --- /dev/null
> +++ linux-can-next/drivers/net/can/rcar_can.c
> @@ -0,0 +1,898 @@
> +/*
> + * Renesas R-Car CAN device driver
> + *
> + * Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
> + * Copyright (C) 2013 Renesas Solutions Corp.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/interrupt.h>
> +#include <linux/errno.h>
> +#include <linux/netdevice.h>
> +#include <linux/platform_device.h>
> +#include <linux/can/led.h>
> +#include <linux/can/dev.h>
> +#include <linux/clk.h>
> +#include <linux/can/platform/rcar_can.h>
> +
> +#define DRV_NAME "rcar_can"
> +
> +#define RCAR_CAN_MIER1 0x42C /* CANi Mailbox Interrupt Enable Register 1 */
> +#define RCAR_CAN_MKR(n) ((n) < 2 ? 0x430 + 4 * (n) : 0x400 + 4 * ((n) - 2))
> + /* CANi Mask Register */
> +#define RCAR_CAN_MKIVLR0 0x438 /* CANi Mask Invalid Register 0 */
> +#define RCAR_CAN_MIER0 0x43C /* CANi Mailbox Interrupt Enable Register 0 */
> +
> +#define RCAR_CAN_MCTL(n) (0x800 + (n)) /* CANi Message Control Register */
> +#define RCAR_CAN_CTLR 0x840 /* CANi Control Register */
> +#define RCAR_CAN_STR 0x842 /* CANi Status Register */
> +#define RCAR_CAN_BCR 0x844 /* CANi Bit Configuration Register */
> +#define RCAR_CAN_CLKR 0x847 /* CANi Clock Select Register */
> +#define RCAR_CAN_EIER 0x84C /* CANi Error Interrupt Enable Register */
> +#define RCAR_CAN_EIFR 0x84D /* CANi Err Interrupt Factor Judge Register */
> +#define RCAR_CAN_RECR 0x84E /* CANi Receive Error Count Register */
> +#define RCAR_CAN_TECR 0x84F /* CANi Transmit Error Count Register */
> +#define RCAR_CAN_ECSR 0x850 /* CANi Error Code Store Register */
> +#define RCAR_CAN_MSSR 0x852 /* CANi Mailbox Search Status Register */
> +#define RCAR_CAN_MSMR 0x853 /* CANi Mailbox Search Mode Register */
> +#define RCAR_CAN_TCR 0x858 /* CANi Test Control Register */
> +#define RCAR_CAN_IER 0x860 /* CANi Interrupt Enable Register */
> +#define RCAR_CAN_ISR 0x861 /* CANi Interrupt Status Register */
CANi on each line!? I would drop it.
> +/* Offsets of RCAR_CAN Mailbox Registers */
> +#define MBX_HDR_OFFSET 0x0
> +#define MBX_DLC_OFFSET 0x5
> +#define MBX_DATA_OFFSET 0x6
I see some advantages in using structs to describe the register layout
here. Better readability, type checking and the macros below will be
obsolete.
> +#define RCAR_CAN_MBX_SIZE 0x10
> +
> +/* Control Register bits */
> +#define CTLR_SLPM BIT(10)
> +#define CTLR_HALT BIT(9)
> +#define CTLR_RESET BIT(8)
> +#define CTLR_FORCE_RESET (3 << 8)
> +#define CTLR_TPM BIT(4) /* Transmission Priority Mode Select Bit */
> +#define CTLR_IDFM_MIXED BIT(2) /* Mixed ID mode */
> +
> +/* Message Control Register bits */
> +#define MCTL_TRMREQ BIT(7)
> +#define MCTL_RECREQ BIT(6)
> +#define MCTL_ONESHOT BIT(4)
> +#define MCTL_SENTDATA BIT(0)
> +#define MCTL_NEWDATA BIT(0)
> +
> +#define N_RX_MKREGS 2 /* Number of mask registers */
> + /* for Rx mailboxes 0-31 */
> +
> +/* Bit Configuration Register settings */
> +#define BCR_TSEG1(x) (((x) & 0x0f) << 28)
> +#define BCR_BPR(x) (((x) & 0x3ff) << 16)
> +#define BCR_SJW(x) (((x) & 0x3) << 12)
> +#define BCR_TSEG2(x) (((x) & 0x07) << 8)
> +
> +/* Mailbox and Mask Registers bits */
> +#define RCAR_CAN_IDE BIT(31)
> +#define RCAR_CAN_RTR BIT(30)
> +#define RCAR_CAN_SID_SHIFT 18
> +
> +/* Interrupt Enable Register bits */
> +#define IER_ERSIE BIT(5) /* Error (ERS) Interrupt Enable Bit */
> +#define IER_RXM0IE BIT(2) /* Mailbox 0 Successful Reception (RXM0) */
> + /* Interrupt Enable Bit */
> +#define IER_RXM1IE BIT(1) /* Mailbox 1 Successful Reception (RXM0) */
> + /* Interrupt Enable Bit */
> +#define IER_TXMIE BIT(0) /* Mailbox 32 to 63 Successful Tx */
> + /* Interrupt Enable Bit */
> +
> +/* Interrupt Status Register bits */
> +#define ISR_ERSF BIT(5) /* Error (ERS) Interrupt Status Bit */
> +#define ISR_RXM0F BIT(2) /* Mailbox 0 Successful Reception (RXM0) */
> + /* Interrupt Status Bit */
> +#define ISR_RXM1F BIT(1) /* Mailbox 1 to 63 Successful Reception */
> + /* (RXM1) Interrupt Status Bit */
> +#define ISR_TXMF BIT(0) /* Mailbox 32 to 63 Successful Transmission */
> + /* (TXM) Interrupt Status Bit */
> +
> +/* Error Interrupt Enable Register bits */
> +#define EIER_BLIE BIT(7) /* Bus Lock Interrupt Enable */
> +#define EIER_OLIE BIT(6) /* Overload Frame Transmit Interrupt Enable */
> +#define EIER_ORIE BIT(5) /* Receive Overrun Interrupt Enable */
> +#define EIER_BORIE BIT(4) /* Bus-Off Recovery Interrupt Enable */
> +
> +#define EIER_BOEIE BIT(3) /* Bus-Off Entry Interrupt Enable */
> +#define EIER_EPIE BIT(2) /* Error Passive Interrupt Enable */
> +#define EIER_EWIE BIT(1) /* Error Warning Interrupt Enable */
> +#define EIER_BEIE BIT(0) /* Bus Error Interrupt Enable */
> +
> +/* Error Interrupt Factor Judge Register bits */
> +#define EIFR_BLIF BIT(7) /* Bus Lock Detect Flag */
> +#define EIFR_OLIF BIT(6) /* Overload Frame Transmission Detect Flag */
> +#define EIFR_ORIF BIT(5) /* Receive Overrun Detect Flag */
> +#define EIFR_BORIF BIT(4) /* Bus-Off Recovery Detect Flag */
> +#define EIFR_BOEIF BIT(3) /* Bus-Off Entry Detect Flag */
> +#define EIFR_EPIF BIT(2) /* Error Passive Detect Flag */
> +#define EIFR_EWIF BIT(1) /* Error Warning Detect Flag */
> +#define EIFR_BEIF BIT(0) /* Bus Error Detect Flag */
> +
> +/* Error Code Store Register bits */
> +#define ECSR_EDPM BIT(7) /* Error Display Mode Select Bit */
> +#define ECSR_ADEF BIT(6) /* ACK Delimiter Error Flag */
> +#define ECSR_BE0F BIT(5) /* Bit Error (dominant) Flag */
> +#define ECSR_BE1F BIT(4) /* Bit Error (recessive) Flag */
> +#define ECSR_CEF BIT(3) /* CRC Error Flag */
> +#define ECSR_AEF BIT(2) /* ACK Error Flag */
> +#define ECSR_FEF BIT(1) /* Form Error Flag */
> +#define ECSR_SEF BIT(0) /* Stuff Error Flag */
> +
> +/* Mailbox Search Status Register bits */
> +#define MSSR_SEST BIT(7) /* Search Result Status Bit */
> +#define MSSR_MBNST 0x3f /* Search Result Mailbox Number Status mask */
> +
> +/* Mailbox Search Mode Register values */
> +#define MSMR_TXMB 1 /* Transmit mailbox search mode */
> +#define MSMR_RXMB 0 /* Receive mailbox search mode */
> +
> +/* Mailbox configuration:
> + * mailbox 0 - not used
> + * mailbox 1-31 - Rx
> + * mailbox 32-63 - Tx
> + * no FIFO mailboxes
> + */
> +#define N_MBX 64
> +#define FIRST_TX_MB 32
> +#define RX_MBX_MASK 0xFFFFFFFE
> +
> +#define RCAR_CAN_NAPI_WEIGHT (FIRST_TX_MB - 1)
> +
> +struct rcar_can_priv {
> + struct can_priv can; /* Must be the first member! */
> + struct net_device *ndev;
> + struct napi_struct napi;
> + void __iomem *reg_base;
> + struct clk *clk;
> + spinlock_t mier_lock;
> + u8 clock_select;
> +};
> +
> +static const struct can_bittiming_const rcar_can_bittiming_const = {
> + .name = DRV_NAME,
> + .tseg1_min = 4,
> + .tseg1_max = 16,
> + .tseg2_min = 2,
> + .tseg2_max = 8,
> + .sjw_max = 4,
> + .brp_min = 1,
> + .brp_max = 1024,
> + .brp_inc = 1,
> +};
> +
> +static inline u32 rcar_can_readl(struct rcar_can_priv *priv, int reg)
> +{
> + return readl(priv->reg_base + reg);
> +}
> +
> +static inline u16 rcar_can_readw(struct rcar_can_priv *priv, int reg)
> +{
> + return readw(priv->reg_base + reg);
> +}
> +
> +static inline u8 rcar_can_readb(struct rcar_can_priv *priv, int reg)
> +{
> + return readb(priv->reg_base + reg);
> +}
> +
> +static inline void rcar_can_writel(struct rcar_can_priv *priv, int reg, u32 val)
> +{
> + writel(val, priv->reg_base + reg);
> +}
> +
> +static inline void rcar_can_writew(struct rcar_can_priv *priv, int reg, u16 val)
> +{
> + writew(val, priv->reg_base + reg);
> +}
> +
> +static inline void rcar_can_writeb(struct rcar_can_priv *priv, int reg, u8 val)
> +{
> + writeb(val, priv->reg_base + reg);
> +}
> +
> +static inline u32 rcar_can_mbx_readl(struct rcar_can_priv *priv,
> + u32 mbxno, u8 offset)
> +{
> + return rcar_can_readl(priv, RCAR_CAN_MBX_SIZE * mbxno + offset);
> +}
> +
> +static inline u8 rcar_can_mbx_readb(struct rcar_can_priv *priv,
> + u32 mbxno, u8 offset)
> +{
> + return rcar_can_readb(priv, RCAR_CAN_MBX_SIZE * mbxno + offset);
> +}
> +
> +static inline void rcar_can_mbx_writel(struct rcar_can_priv *priv, u32 mbxno,
> + u8 offset, u32 val)
> +{
> + rcar_can_writel(priv, RCAR_CAN_MBX_SIZE * mbxno + offset, val);
> +}
> +
> +static inline void rcar_can_mbx_writeb(struct rcar_can_priv *priv, u32 mbxno,
> + u8 offset, u8 val)
> +{
> + rcar_can_writeb(priv, RCAR_CAN_MBX_SIZE * mbxno + offset, val);
> +}
See my comment above. Reading the DLC from the mailbox could then be
done with:
writeb(val, &priv->regs.mb[mbxno].dlc]);
> +static void rcar_can_error(struct net_device *ndev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> + struct net_device_stats *stats = &ndev->stats;
> + struct can_frame *cf;
> + struct sk_buff *skb;
> + u8 eifr;
> +
> + /* Propagate the error condition to the CAN stack */
> + skb = alloc_can_err_skb(ndev, &cf);
> + if (!skb) {
> + if (printk_ratelimit())
> + netdev_err(priv->ndev,
> + "%s: alloc_can_err_skb() failed\n",
> + __func__);
> + return;
> + }
IIRC, the policy is to return silently here. I only see the ti_hecc
driver is using printk_ratelimit(). Marc?
> + eifr = rcar_can_readb(priv, RCAR_CAN_EIFR);
> + if (eifr & EIFR_EWIF) {
> + netdev_dbg(priv->ndev, "Error warning interrupt\n");
> + priv->can.state = CAN_STATE_ERROR_WARNING;
> + priv->can.can_stats.error_warning++;
> + cf->can_id |= CAN_ERR_CRTL;
> + if (rcar_can_readb(priv, RCAR_CAN_TECR) > 96)
> + cf->data[1] |= CAN_ERR_CRTL_TX_WARNING;
> + if (rcar_can_readb(priv, RCAR_CAN_RECR) > 96)
> + cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> + /* Clear interrupt condition */
> + rcar_can_writeb(priv, RCAR_CAN_EIFR, (u8)~EIFR_EWIF);
Please avoid casts. I think they are not needed anyway (here and below).
> + }
> + if (eifr & EIFR_EPIF) {
> + netdev_dbg(priv->ndev, "Error passive interrupt\n");
> + priv->can.state = CAN_STATE_ERROR_PASSIVE;
> + priv->can.can_stats.error_passive++;
> + cf->can_id |= CAN_ERR_CRTL;
> + if (rcar_can_readb(priv, RCAR_CAN_TECR) > 127)
> + cf->data[1] |= CAN_ERR_CRTL_TX_PASSIVE;
> + if (rcar_can_readb(priv, RCAR_CAN_RECR) > 127)
> + cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
> + /* Clear interrupt condition */
> + rcar_can_writeb(priv, RCAR_CAN_EIFR, (u8)~EIFR_EPIF);
> + }
> + if (eifr & EIFR_BOEIF) {
> + netdev_dbg(priv->ndev, "Bus-off entry interrupt\n");
> + priv->can.state = CAN_STATE_BUS_OFF;
> + cf->can_id |= CAN_ERR_BUSOFF;
> + /* Clear interrupt condition */
> + rcar_can_writeb(priv, RCAR_CAN_EIFR, (u8)~EIFR_BOEIF);
> + /* Disable all interrupts in bus-off to avoid int hog */
> + rcar_can_writeb(priv, RCAR_CAN_EIER, 0);
> + rcar_can_writeb(priv, RCAR_CAN_IER, 0);
> + can_bus_off(ndev);
> + }
> + if (eifr & EIFR_BEIF) {
> + int rx_errors = 0, tx_errors = 0, bus_errors = 0;
> + u8 ecsr;
> +
> + netdev_dbg(priv->ndev, "Bus error interrupt:\n");
> + cf->can_id |= CAN_ERR_BUSERROR | CAN_ERR_PROT;
> + cf->data[2] = CAN_ERR_PROT_UNSPEC;
I think you can increment bus errors here for all types.:
bus_errors++;
> +
> + ecsr = rcar_can_readb(priv, RCAR_CAN_ECSR);
> + if (ecsr & ECSR_ADEF) {
> + netdev_dbg(priv->ndev, "ACK Delimiter Error\n");
> + cf->data[3] |= CAN_ERR_PROT_LOC_ACK_DEL;
> + bus_errors++;
> + tx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_ADEF);
> + }
> + if (ecsr & ECSR_BE0F) {
> + netdev_dbg(priv->ndev, "Bit Error (dominant)\n");
> + cf->data[2] |= CAN_ERR_PROT_BIT0;
> + bus_errors++;
> + tx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_BE0F);
> + }
> + if (ecsr & ECSR_BE1F) {
> + netdev_dbg(priv->ndev, "Bit Error (recessive)\n");
> + cf->data[2] |= CAN_ERR_PROT_BIT1;
> + bus_errors++;
> + tx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_BE1F);
> + }
> + if (ecsr & ECSR_CEF) {
> + netdev_dbg(priv->ndev, "CRC Error\n");
> + cf->data[3] |= CAN_ERR_PROT_LOC_CRC_SEQ;
> + bus_errors++;
> + rx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_CEF);
> + }
> + if (ecsr & ECSR_AEF) {
> + netdev_dbg(priv->ndev, "ACK Error\n");
> + cf->data[3] |= CAN_ERR_PROT_LOC_ACK;
Please add here:
cf->can_id |= CAN_ERR_ACK;
> + bus_errors++;
> + tx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_AEF);
> + }
> + if (ecsr & ECSR_FEF) {
> + netdev_dbg(priv->ndev, "Form Error\n");
> + cf->data[2] |= CAN_ERR_PROT_FORM;
> + bus_errors++;
> + rx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_FEF);
> + }
> + if (ecsr & ECSR_SEF) {
> + netdev_dbg(priv->ndev, "Stuff Error\n");
> + cf->data[2] |= CAN_ERR_PROT_STUFF;
> + bus_errors++;
> + rx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_SEF);
> + }
> +
> + priv->can.can_stats.bus_error += bus_errors;
> + ndev->stats.rx_errors += rx_errors;
> + ndev->stats.tx_errors += tx_errors;
> + rcar_can_writeb(priv, RCAR_CAN_EIFR, (u8)~EIFR_BEIF);
> + }
> + if (eifr & EIFR_ORIF) {
> + netdev_dbg(priv->ndev, "Receive overrun error interrupt\n");
> + cf->can_id |= CAN_ERR_CRTL;
> + cf->data[1] |= CAN_ERR_CRTL_RX_OVERFLOW;
> + ndev->stats.rx_over_errors++;
> + ndev->stats.rx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_EIFR, (u8)~EIFR_ORIF);
> + }
> + if (eifr & EIFR_OLIF) {
> + netdev_dbg(priv->ndev,
> + "Overload Frame Transmission error interrupt\n");
> + cf->can_id |= CAN_ERR_PROT;
> + cf->data[2] |= CAN_ERR_PROT_OVERLOAD;
> + ndev->stats.rx_over_errors++;
> + ndev->stats.rx_errors++;
> + rcar_can_writeb(priv, RCAR_CAN_EIFR, (u8)~EIFR_OLIF);
> + }
> +
> + netif_rx(skb);
> + stats->rx_packets++;
> + stats->rx_bytes += cf->can_dlc;
> +}
> +
> +static irqreturn_t rcar_can_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *ndev = (struct net_device *)dev_id;
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> + struct net_device_stats *stats = &ndev->stats;
> + u8 isr;
> +
> + isr = rcar_can_readb(priv, RCAR_CAN_ISR);
> + if (isr & ISR_ERSF)
> + rcar_can_error(ndev);
> +
> + if (isr & ISR_TXMF) {
> + u32 ie_mask = 0;
> +
> + /* Set Transmit Mailbox Search Mode */
> + rcar_can_writeb(priv, RCAR_CAN_MSMR, MSMR_TXMB);
> + while (1) {
> + u8 mctl, mbx;
> +
> + mbx = rcar_can_readb(priv, RCAR_CAN_MSSR);
> + if (mbx & MSSR_SEST)
> + break;
> + mbx &= MSSR_MBNST;
> + mctl = rcar_can_readb(priv, RCAR_CAN_MCTL(mbx));
> + /* Bits SENTDATA and TRMREQ cannot be
> + * set to 0 simultaneously
> + */
> + mctl &= ~MCTL_TRMREQ;
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(mbx), mctl);
> + mctl &= ~MCTL_SENTDATA;
> + /* Clear interrupt */
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(mbx), mctl);
> + ie_mask |= BIT(mbx - FIRST_TX_MB);
> + stats->tx_bytes += can_get_echo_skb(ndev,
> + mbx - FIRST_TX_MB);
can_get_echo_skb() may return 0 because local loopback can be disabled
by the user.
> + stats->tx_packets++;
> + can_led_event(ndev, CAN_LED_EVENT_TX);
> + }
> + /* Set receive mailbox search mode */
> + rcar_can_writeb(priv, RCAR_CAN_MSMR, MSMR_RXMB);
> + /* Disable mailbox interrupt, mark mailbox as free */
> + if (ie_mask) {
> + u32 mier1;
> +
> + spin_lock(&priv->mier_lock);
> + mier1 = rcar_can_readl(priv, RCAR_CAN_MIER1);
> + rcar_can_writel(priv, RCAR_CAN_MIER1, mier1 & ~ie_mask);
> + spin_unlock(&priv->mier_lock);
> + if (unlikely(netif_queue_stopped(ndev)))
> + netif_wake_queue(ndev);
> + }
> + }
> + if (isr & ISR_RXM1F) {
> + if (napi_schedule_prep(&priv->napi)) {
> + /* Disable Rx interrupts */
> + rcar_can_writeb(priv, RCAR_CAN_IER,
> + rcar_can_readb(priv, RCAR_CAN_IER) &
> + ~IER_RXM1IE);
> + __napi_schedule(&priv->napi);
> + }
> + }
> + return IRQ_HANDLED;
> +}
> +
> +static int rcar_can_set_bittiming(struct net_device *dev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(dev);
> + struct can_bittiming *bt = &priv->can.bittiming;
> + u32 bcr;
> + u16 ctlr;
> + u8 clkr;
> +
> + ctlr = rcar_can_readw(priv, RCAR_CAN_CTLR);
> + if (ctlr & CTLR_SLPM) {
> + /* Write to BCR in CAN reset mode or CAN halt mode */
> + return -EBUSY;
> + }
> + /* Don't overwrite CLKR with 32-bit BCR access */
> + /* CLKR has 8-bit access */
> + clkr = rcar_can_readb(priv, RCAR_CAN_CLKR);
> + bcr = BCR_TSEG1(bt->phase_seg1 + bt->prop_seg - 1) |
> + BCR_BPR(bt->brp - 1) | BCR_SJW(bt->sjw - 1) |
> + BCR_TSEG2(bt->phase_seg2 - 1);
> + rcar_can_writel(priv, RCAR_CAN_BCR, bcr);
> + rcar_can_writeb(priv, RCAR_CAN_CLKR, clkr);
> + return 0;
What about support for CAN_CTRLMODE_3_SAMPLES?
> +}
> +
> +static void rcar_can_start(struct net_device *ndev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> + u16 ctlr, n;
> +
> + /* Set controller to known mode:
> + * - normal mailbox mode (no FIFO);
> + * - accept all messages (no filter).
> + * CAN is in sleep mode after MCU hardware or software reset.
> + */
> + ctlr = rcar_can_readw(priv, RCAR_CAN_CTLR);
> + ctlr &= ~CTLR_SLPM;
> + rcar_can_writew(priv, RCAR_CAN_CTLR, ctlr);
> + /* Go to reset mode */
> + ctlr |= CTLR_FORCE_RESET;
> + rcar_can_writew(priv, RCAR_CAN_CTLR, ctlr);
> + ctlr |= CTLR_IDFM_MIXED; /* Select mixed ID mode */
> + ctlr &= ~CTLR_TPM; /* Set ID priority transmit mode */
> + rcar_can_writew(priv, RCAR_CAN_CTLR, ctlr);
> +
> + rcar_can_writeb(priv, RCAR_CAN_CLKR, priv->clock_select);
> +
> + /* Accept all SID and EID */
> + for (n = 0; n < N_RX_MKREGS; n++)
> + rcar_can_writel(priv, RCAR_CAN_MKR(n), 0);
> + rcar_can_writel(priv, RCAR_CAN_MKIVLR0, 0);
> +
> + rcar_can_set_bittiming(ndev);
> +
> + /* Initial value of MIER1 undefined. Mark all Tx mailboxes as free. */
> + rcar_can_writel(priv, RCAR_CAN_MIER1, 0);
> +
> + rcar_can_writeb(priv, RCAR_CAN_IER, IER_TXMIE | IER_ERSIE | IER_RXM1IE);
> +
> + /* Accumulate error codes */
> + rcar_can_writeb(priv, RCAR_CAN_ECSR, ECSR_EDPM);
> + /* Enable error interrupts */
> + rcar_can_writeb(priv, RCAR_CAN_EIER,
> + EIER_EWIE | EIER_EPIE | EIER_BOEIE | EIER_BEIE |
> + EIER_ORIE | EIER_OLIE);
Bus error reporting might result in heavy system load, especially
because they are handled in the irq context. For this purpose we have
the CAN_CTRLMODE_BERR_REPORTING flag. Shoudl not be a big deal to
support it here (if the hardware is working properly):
rcar_can_writeb(priv, RCAR_CAN_EIER,
EIER_EWIE | EIER_EPIE | EIER_BOEIE |
(priv->can.ctrlmode &
CAN_CTRLMODE_BERR_REPORTING ? EIER_BEIE : 0) |
EIER_ORIE | EIER_OLIE);
> + /* Enable interrupts for RX mailboxes */
> + rcar_can_writel(priv, RCAR_CAN_MIER0, RX_MBX_MASK);
> + priv->can.state = CAN_STATE_ERROR_ACTIVE;
> +
> + /* Write to the CiMCTLj register in CAN
> + * operation mode or CAN halt mode.
> + * Configure mailboxes 0-31 as Rx mailboxes.
> + * Configure mailboxes 32-63 as Tx mailboxes.
> + */
> + /* Go to halt mode */
> + ctlr |= CTLR_HALT;
> + ctlr &= ~CTLR_RESET;
> + rcar_can_writew(priv, RCAR_CAN_CTLR, ctlr);
> + for (n = 0; n < FIRST_TX_MB; n++) {
> + /* According to documentation we should clear MCTL
> + * register before configuring mailbox.
> + */
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(n), 0);
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(n), MCTL_RECREQ);
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(FIRST_TX_MB + n), 0);
> + }
> + /* Go to operation mode */
> + rcar_can_writew(priv, RCAR_CAN_CTLR, ctlr & ~CTLR_FORCE_RESET);
> +}
> +
> +static int rcar_can_open(struct net_device *ndev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> + int err;
> +
> + err = open_candev(ndev);
> + if (err) {
> + netdev_err(ndev, "open_candev() failed %d\n", err);
> + goto out;
> + }
> + napi_enable(&priv->napi);
> + err = request_irq(ndev->irq, rcar_can_interrupt, 0, ndev->name, ndev);
> + if (err) {
> + netdev_err(ndev, "error requesting interrupt %x\n", ndev->irq);
> + goto out_close;
> + }
> + can_led_event(ndev, CAN_LED_EVENT_OPEN);
> + rcar_can_start(ndev);
> + netif_start_queue(ndev);
> + return 0;
> +out_close:
> + napi_disable(&priv->napi);
> + close_candev(ndev);
> +out:
> + return err;
> +}
> +
> +static void rcar_can_stop(struct net_device *ndev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> + u16 ctlr;
> +
> + /* Go to (force) reset mode */
> + ctlr = rcar_can_readw(priv, RCAR_CAN_CTLR);
> + rcar_can_writew(priv, RCAR_CAN_CTLR, ctlr | CTLR_FORCE_RESET);
> + rcar_can_writel(priv, RCAR_CAN_MIER0, 0);
> + rcar_can_writel(priv, RCAR_CAN_MIER1, 0);
> + rcar_can_writeb(priv, RCAR_CAN_IER, 0);
> + rcar_can_writeb(priv, RCAR_CAN_EIER, 0);
> + priv->can.state = CAN_STATE_STOPPED;
> +}
> +
> +static int rcar_can_close(struct net_device *ndev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> +
> + netif_stop_queue(ndev);
> + rcar_can_stop(ndev);
> + free_irq(ndev->irq, ndev);
> + napi_disable(&priv->napi);
> + close_candev(ndev);
> + can_led_event(ndev, CAN_LED_EVENT_STOP);
> + return 0;
> +}
> +
> +static netdev_tx_t rcar_can_start_xmit(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + struct rcar_can_priv *priv = netdev_priv(ndev);
> + struct can_frame *cf = (struct can_frame *)skb->data;
> + u32 data, mier1, mbxno, i;
> + unsigned long flags;
> + u8 mctl;
> +
> + if (can_dropped_invalid_skb(ndev, skb))
> + return NETDEV_TX_OK;
> +
> + spin_lock_irqsave(&priv->mier_lock, flags);
> + mier1 = rcar_can_readl(priv, RCAR_CAN_MIER1);
> + if (unlikely(mier1 == ~0U)) {
> + spin_unlock_irqrestore(&priv->mier_lock, flags);
> + netif_stop_queue(ndev);
> + return NETDEV_TX_BUSY;
> + }
I think it is possible the avoid the "return NETDEV_TX_BUSY" here in
most cases if you stop the queue at the end of the previous message.
> + rcar_can_writel(priv, RCAR_CAN_MIER1, mier1 | (mier1 + 1));
> + spin_unlock_irqrestore(&priv->mier_lock, flags);
> + mbxno = ffz(mier1) + FIRST_TX_MB;
How to you handle "mbxno" wrap around. Are messages then still send out
in order?
> +
> + if (cf->can_id & CAN_EFF_FLAG) {
> + /* Extended frame format */
> + data = (cf->can_id & CAN_EFF_MASK) | RCAR_CAN_IDE;
> + } else {
> + /* Standard frame format */
> + data = (cf->can_id & CAN_SFF_MASK) << RCAR_CAN_SID_SHIFT;
> + }
> + if (cf->can_id & CAN_RTR_FLAG) {
> + /* Remote transmission request */
> + data |= RCAR_CAN_RTR;
> + }
> + rcar_can_mbx_writel(priv, mbxno, MBX_HDR_OFFSET, data);
> +
> + rcar_can_mbx_writeb(priv, mbxno, MBX_DLC_OFFSET, cf->can_dlc);
> +
> + for (i = 0; i < cf->can_dlc; i++)
> + rcar_can_mbx_writeb(priv, mbxno,
> + MBX_DATA_OFFSET + i, cf->data[i]);
> +
> + can_put_echo_skb(skb, ndev, mbxno - FIRST_TX_MB);
> +
> + rcar_can_writeb(priv, RCAR_CAN_IER,
> + rcar_can_readb(priv, RCAR_CAN_IER) | IER_TXMIE);
> +
> + mctl = rcar_can_readb(priv, RCAR_CAN_MCTL(mbxno));
> + if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)
> + mctl |= MCTL_ONESHOT;
> + else
> + mctl &= ~MCTL_ONESHOT;
> + /* Start TX */
> + mctl |= MCTL_TRMREQ;
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(mbxno), mctl);
> + return NETDEV_TX_OK;
> +}
> +
> +static const struct net_device_ops rcar_can_netdev_ops = {
> + .ndo_open = rcar_can_open,
> + .ndo_stop = rcar_can_close,
> + .ndo_start_xmit = rcar_can_start_xmit,
> +};
> +
> +static void rcar_can_rx_pkt(struct rcar_can_priv *priv, int mbx)
> +{
> + struct net_device_stats *stats = &priv->ndev->stats;
> + struct can_frame *cf;
> + struct sk_buff *skb;
> + u32 data;
> + u8 dlc;
> +
> + skb = alloc_can_skb(priv->ndev, &cf);
> + if (!skb) {
> + stats->rx_dropped++;
> + if (printk_ratelimit())
> + netdev_err(priv->ndev,
> + "%s: alloc_can_skb() failed\n", __func__);
> + return;
> + }
Same comment as for alloc_can_err_skb().
> + data = rcar_can_mbx_readl(priv, mbx, MBX_HDR_OFFSET);
> + if (data & RCAR_CAN_IDE)
> + cf->can_id = (data & CAN_EFF_MASK) | CAN_EFF_FLAG;
> + else
> + cf->can_id = (data >> RCAR_CAN_SID_SHIFT) & CAN_SFF_MASK;
> + if (data & RCAR_CAN_RTR)
> + cf->can_id |= CAN_RTR_FLAG;
IIRC, we should not copy data for RTR frames. At least for the SJA1000
we fixed:
commit 87e9af6cc67d842cd92b52b81f3f14e665e7ab05
Author: Kurt Van Dijck <kurt.van.dijck@eia.be>
Date: Mon May 2 04:50:48 2011 +0000
can: fix SJA1000 dlc for RTR packets
RTR frames do have a valid data length code on CAN.
The driver for SJA1000 did not handle that situation properly.
But I see that not all drivers do respect that rule.
> +
> + dlc = rcar_can_mbx_readb(priv, mbx, MBX_DLC_OFFSET);
> + cf->can_dlc = get_can_dlc(dlc);
> + for (dlc = 0; dlc < cf->can_dlc; dlc++)
> + cf->data[dlc] = rcar_can_mbx_readb(priv, mbx,
> + MBX_DATA_OFFSET + dlc);
> +
> + can_led_event(priv->ndev, CAN_LED_EVENT_RX);
> +
> + netif_receive_skb(skb);
> + stats->rx_bytes += cf->can_dlc;
> + stats->rx_packets++;
> +}
> +
> +static int rcar_can_rx_poll(struct napi_struct *napi, int quota)
> +{
> + struct rcar_can_priv *priv = container_of(napi,
> + struct rcar_can_priv, napi);
> + u32 num_pkts = 0;
> +
> + /* Find mailbox */
> + while (1) {
> + u8 mctl, mbx;
> +
> + mbx = rcar_can_readb(priv, RCAR_CAN_MSSR);
> + if (mbx & MSSR_SEST || num_pkts >= quota)
> + break;
> + mbx &= MSSR_MBNST;
> + mctl = rcar_can_readb(priv, RCAR_CAN_MCTL(mbx));
> + /* Clear interrupt */
> + rcar_can_writeb(priv, RCAR_CAN_MCTL(mbx),
> + mctl & ~MCTL_NEWDATA);
> + rcar_can_rx_pkt(priv, mbx);
> + ++num_pkts;
> + }
> + /* All packets processed */
> + if (num_pkts < quota) {
> + u8 ier;
> +
> + napi_complete(napi);
> + ier = rcar_can_readb(priv, RCAR_CAN_IER);
> + rcar_can_writeb(priv, RCAR_CAN_IER, ier | IER_RXM1IE);
> + }
> + return num_pkts;
> +}
> +
> +static int rcar_can_do_set_mode(struct net_device *ndev, enum can_mode mode)
> +{
> + switch (mode) {
> + case CAN_MODE_START:
> + rcar_can_start(ndev);
> + netif_wake_queue(ndev);
> + return 0;
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int rcar_can_get_berr_counter(const struct net_device *dev,
> + struct can_berr_counter *bec)
> +{
> + struct rcar_can_priv *priv = netdev_priv(dev);
> +
> + bec->txerr = rcar_can_readb(priv, RCAR_CAN_TECR);
> + bec->rxerr = rcar_can_readb(priv, RCAR_CAN_RECR);
> + return 0;
> +}
> +
> +static int rcar_can_probe(struct platform_device *pdev)
> +{
> + struct rcar_can_platform_data *pdata;
> + struct rcar_can_priv *priv;
> + struct net_device *ndev;
> + struct resource *mem;
> + void __iomem *addr;
> + int err = -ENODEV;
> + int irq;
> +
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + dev_err(&pdev->dev, "No platform data provided!\n");
> + goto fail;
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (!irq) {
> + dev_err(&pdev->dev, "No IRQ resource\n");
> + goto fail;
> + }
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + addr = devm_ioremap_resource(&pdev->dev, mem);
> + if (IS_ERR(addr)) {
> + err = PTR_ERR(addr);
> + goto fail;
> + }
> +
> + ndev = alloc_candev(sizeof(struct rcar_can_priv), N_MBX - FIRST_TX_MB);
> + if (!ndev) {
> + dev_err(&pdev->dev, "alloc_candev failed\n");
> + err = -ENOMEM;
> + goto fail;
> + }
> +
> + priv = netdev_priv(ndev);
> +
> + priv->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(priv->clk)) {
> + err = PTR_ERR(priv->clk);
> + dev_err(&pdev->dev, "cannot get clock: %d\n", err);
> + goto fail_clk;
> + }
> + clk_enable(priv->clk);
> +
> + ndev->netdev_ops = &rcar_can_netdev_ops;
> + ndev->irq = irq;
> + ndev->flags |= IFF_ECHO;
> + priv->ndev = ndev;
> + priv->reg_base = addr;
> + priv->clock_select = pdata->clock_select;
> + priv->can.clock.freq = clk_get_rate(priv->clk);
> + priv->can.bittiming_const = &rcar_can_bittiming_const;
> + priv->can.do_set_bittiming = rcar_can_set_bittiming;
rcar_can_set_bittiming() is already called in the open function. Is this
intended?
Wolfgang.
^ permalink raw reply
* [PATCH] can: dev: fix nlmsg size calculation in can_get_size()
From: Marc Kleine-Budde @ 2013-10-05 19:25 UTC (permalink / raw)
To: netdev; +Cc: linux-can, kernel, Wolfgang Grandegger, Marc Kleine-Budde
This patch fixes the calculation of the nlmsg size, by adding the missing
nla_total_size().
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Hello,
this patch touches the rtnl_link_ops get_size() callback:
static struct rtnl_link_ops can_link_ops __read_mostly = {
...
.get_size = can_get_size,
...
};
By looking at other nlmsg size calculation I think a nla_total_size() for all
contributers is needed. Am I correct?
regards,
Marc
drivers/net/can/dev.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index f9cba41..1870c47 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -705,14 +705,14 @@ static size_t can_get_size(const struct net_device *dev)
size_t size;
size = nla_total_size(sizeof(u32)); /* IFLA_CAN_STATE */
- size += sizeof(struct can_ctrlmode); /* IFLA_CAN_CTRLMODE */
+ size += nla_total_size(sizeof(struct can_ctrlmode)); /* IFLA_CAN_CTRLMODE */
size += nla_total_size(sizeof(u32)); /* IFLA_CAN_RESTART_MS */
- size += sizeof(struct can_bittiming); /* IFLA_CAN_BITTIMING */
- size += sizeof(struct can_clock); /* IFLA_CAN_CLOCK */
+ size += nla_total_size(sizeof(struct can_bittiming)); /* IFLA_CAN_BITTIMING */
+ size += nla_total_size(sizeof(struct can_clock)); /* IFLA_CAN_CLOCK */
if (priv->do_get_berr_counter) /* IFLA_CAN_BERR_COUNTER */
- size += sizeof(struct can_berr_counter);
+ size += nla_total_size(sizeof(struct can_berr_counter));
if (priv->bittiming_const) /* IFLA_CAN_BITTIMING_CONST */
- size += sizeof(struct can_bittiming_const);
+ size += nla_total_size(sizeof(struct can_bittiming_const));
return size;
}
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH] net: Update the sysctl permissions handler to test effective uid/gid
From: Eric W. Biederman @ 2013-10-05 20:15 UTC (permalink / raw)
To: David Miller
Cc: Eric Sandeen, Andrew Morton, security@kernel.org, Petr Matousek,
netdev, Kees Cook
In-Reply-To: <CAGXu5j+88Bb0Mnbiyq-bTzkn59YXOefCrXtht-evYhq-yUfYFg@mail.gmail.com>
On Tue, 20 Aug 2013 11:40:04 -0500 Eric Sandeen <sandeen@redhat.com> wrote:
> This was brought up in a Red Hat bug (which may be marked private, I'm sorry):
>
> Bug 987055 - open O_WRONLY succeeds on some root owned files in /proc for process running with unprivileged EUID
>
> "On RHEL7 some of the files in /proc can be opened for writing by an unprivileged EUID."
>
> The flaw existed upstream as well last I checked.
>
> This commit in kernel v3.8 caused the regression:
>
> commit cff109768b2d9c03095848f4cd4b0754117262aa
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date: Fri Nov 16 03:03:01 2012 +0000
>
> net: Update the per network namespace sysctls to be available to the network namespace owner
>
> - Allow anyone with CAP_NET_ADMIN rights in the user namespace of the
> the netowrk namespace to change sysctls.
> - Allow anyone the uid of the user namespace root the same
> permissions over the network namespace sysctls as the global root.
> - Allow anyone with gid of the user namespace root group the same
> permissions over the network namespace sysctl as the global root group.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> because it changed /sys/net's special permission handler to test current_uid, not
> current_euid; same for current_gid/current_egid.
>
> So in this case, root cannot drop privs via set[ug]id, and retains all privs
> in this codepath.
Modify the code to use current_euid(), and in_egroup_p, as in done
in fs/proc/proc_sysctl.c:test_perm()
Cc: stable@vger.kernel.org
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
Resubmitting as it looks like this fix got lost. This patch applies
cleanly against both net-next and linux-3.12-rc1, and likely quite a few
early kernel revisions.
net/sysctl_net.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sysctl_net.c b/net/sysctl_net.c
index 9bc6db04be3e..e7000be321b0 100644
--- a/net/sysctl_net.c
+++ b/net/sysctl_net.c
@@ -47,12 +47,12 @@ static int net_ctl_permissions(struct ctl_table_header *head,
/* Allow network administrator to have same access as root. */
if (ns_capable(net->user_ns, CAP_NET_ADMIN) ||
- uid_eq(root_uid, current_uid())) {
+ uid_eq(root_uid, current_euid())) {
int mode = (table->mode >> 6) & 7;
return (mode << 6) | (mode << 3) | mode;
}
/* Allow netns root group to have the same access as the root group */
- if (gid_eq(root_gid, current_gid())) {
+ if (in_egroup_p(root_gid)) {
int mode = (table->mode >> 3) & 7;
return (mode << 3) | mode;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: Fabio Estevam @ 2013-10-05 20:09 UTC (permalink / raw)
To: davem; +Cc: edumazet, hannes, netdev, olof, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Commit 9a3bab6b05 (net: net_secret should not depend on TCP) introduced
the following build warning when CONFIG_IPV6 is not selected:
net/core/secure_seq.c:17:13: warning: 'net_secret_init' defined but not used [-Wunused-function]
Fix it by moving net_secret_init(void) inside the '#if IS_ENABLED(CONFIG_IPV6)'
block.
Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
net/core/secure_seq.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
index 3f1ec15..ee70541 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -10,6 +10,24 @@
#include <net/secure_seq.h>
+#ifdef CONFIG_INET
+static u32 seq_scale(u32 seq)
+{
+ /*
+ * As close as possible to RFC 793, which
+ * suggests using a 250 kHz clock.
+ * Further reading shows this assumes 2 Mb/s networks.
+ * For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
+ * For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but
+ * we also need to limit the resolution so that the u32 seq
+ * overlaps less than one time per MSL (2 minutes).
+ * Choosing a clock of 64 ns period is OK. (period of 274 s)
+ */
+ return seq + (ktime_to_ns(ktime_get_real()) >> 6);
+}
+#endif
+
+#if IS_ENABLED(CONFIG_IPV6)
#define NET_SECRET_SIZE (MD5_MESSAGE_BYTES / 4)
static u32 net_secret[NET_SECRET_SIZE] ____cacheline_aligned;
@@ -30,24 +48,6 @@ static void net_secret_init(void)
}
}
-#ifdef CONFIG_INET
-static u32 seq_scale(u32 seq)
-{
- /*
- * As close as possible to RFC 793, which
- * suggests using a 250 kHz clock.
- * Further reading shows this assumes 2 Mb/s networks.
- * For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
- * For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but
- * we also need to limit the resolution so that the u32 seq
- * overlaps less than one time per MSL (2 minutes).
- * Choosing a clock of 64 ns period is OK. (period of 274 s)
- */
- return seq + (ktime_to_ns(ktime_get_real()) >> 6);
-}
-#endif
-
-#if IS_ENABLED(CONFIG_IPV6)
__u32 secure_tcpv6_sequence_number(const __be32 *saddr, const __be32 *daddr,
__be16 sport, __be16 dport)
{
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: Fabio Estevam @ 2013-10-05 20:26 UTC (permalink / raw)
To: David S. Miller
Cc: edumazet, netdev@vger.kernel.org, Olof Johansson, Fabio Estevam,
Hannes Frederic Sowa
In-Reply-To: <1381003790-12731-1-git-send-email-festevam@gmail.com>
On Sat, Oct 5, 2013 at 5:09 PM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Commit 9a3bab6b05 (net: net_secret should not depend on TCP) introduced
> the following build warning when CONFIG_IPV6 is not selected:
>
> net/core/secure_seq.c:17:13: warning: 'net_secret_init' defined but not used [-Wunused-function]
>
> Fix it by moving net_secret_init(void) inside the '#if IS_ENABLED(CONFIG_IPV6)'
> block.
>
> Reported-by: Olof Johansson <olof@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Another solution would be:
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -10,6 +10,7 @@
#include <net/secure_seq.h>
+#if IS_ENABLED(CONFIG_IPV6)
#define NET_SECRET_SIZE (MD5_MESSAGE_BYTES / 4)
static u32 net_secret[NET_SECRET_SIZE] ____cacheline_aligned;
@@ -29,6 +30,7 @@ static void net_secret_init(void)
cmpxchg(&net_secret[--i], 0, tmp);
}
}
+#endif
If this is preferred, I can send a v2 like that.
^ permalink raw reply
* Re: [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: David Miller @ 2013-10-05 20:27 UTC (permalink / raw)
To: festevam; +Cc: edumazet, hannes, netdev, olof, fabio.estevam
In-Reply-To: <1381003790-12731-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Sat, 5 Oct 2013 17:09:50 -0300
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Commit 9a3bab6b05 (net: net_secret should not depend on TCP) introduced
> the following build warning when CONFIG_IPV6 is not selected:
>
> net/core/secure_seq.c:17:13: warning: 'net_secret_init' defined but not used [-Wunused-function]
>
> Fix it by moving net_secret_init(void) inside the '#if IS_ENABLED(CONFIG_IPV6)'
> block.
>
> Reported-by: Olof Johansson <olof@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
seq_scale is used by secure_tcp_sequence_number, which is only protected
by CONFIG_INET. I have no idea how you can get this build problem.
And I cannot reproduce it here:
[davem@drr net]$ egrep CONFIG_IPV6 .config
# CONFIG_IPV6 is not set
[davem@drr net]$ make net/core/secure_seq.o
scripts/kconfig/conf --silentoldconfig Kconfig
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `relocs'.
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CC net/core/secure_seq.o
[davem@drr net]$
Furthermore your commit message is talking about net_secret_init but
your patch does things with seq_scale.
I'm not applying this patch.
^ 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