* [PATCH 01/11] batman-adv: report compat_version in version field in case of version mismatch
From: Marek Lindner @ 2011-12-12 11:31 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Marek Lindner, Sven Eckelmann
In-Reply-To: <1323689516-24427-1-git-send-email-lindner_marek@yahoo.de>
Reported-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/icmp_socket.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/batman-adv/icmp_socket.c b/net/batman-adv/icmp_socket.c
index ac3520e..defd692 100644
--- a/net/batman-adv/icmp_socket.c
+++ b/net/batman-adv/icmp_socket.c
@@ -217,7 +217,7 @@ static ssize_t bat_socket_write(struct file *file, const char __user *buff,
if (icmp_packet->version != COMPAT_VERSION) {
icmp_packet->msg_type = PARAMETER_PROBLEM;
- icmp_packet->ttl = COMPAT_VERSION;
+ icmp_packet->version = COMPAT_VERSION;
bat_socket_add_packet(socket_client, icmp_packet, packet_len);
goto free_skb;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 10/11] batman-adv: Directly check read of icmp packet in copy_from_user
From: Marek Lindner @ 2011-12-12 11:31 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner
In-Reply-To: <1323689516-24427-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
The access_ok read check can be directly done in copy_from_user since a failure
of access_ok is handled the same way as an error in __copy_from_user.
Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Signed-off-by: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
---
net/batman-adv/icmp_socket.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/net/batman-adv/icmp_socket.c b/net/batman-adv/icmp_socket.c
index 88ab26f..3b04fff 100644
--- a/net/batman-adv/icmp_socket.c
+++ b/net/batman-adv/icmp_socket.c
@@ -187,12 +187,7 @@ static ssize_t bat_socket_write(struct file *file, const char __user *buff,
skb_reserve(skb, sizeof(struct ethhdr));
icmp_packet = (struct icmp_packet_rr *)skb_put(skb, packet_len);
- if (!access_ok(VERIFY_READ, buff, packet_len)) {
- len = -EFAULT;
- goto free_skb;
- }
-
- if (__copy_from_user(icmp_packet, buff, packet_len)) {
+ if (copy_from_user(icmp_packet, buff, packet_len)) {
len = -EFAULT;
goto free_skb;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 09/11] batman-adv: bat_socket_read missing checks
From: Marek Lindner @ 2011-12-12 11:31 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Marek Lindner,
Paul Kot
In-Reply-To: <1323689516-24427-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Paul Kot <pawlkt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Writing a icmp_packet_rr and then reading icmp_packet can lead to kernel
memory corruption, if __user *buf is just below TASK_SIZE.
Signed-off-by: Paul Kot <pawlkt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org: made it checkpatch clean]
Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Signed-off-by: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
---
net/batman-adv/icmp_socket.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/icmp_socket.c b/net/batman-adv/icmp_socket.c
index defd692..88ab26f 100644
--- a/net/batman-adv/icmp_socket.c
+++ b/net/batman-adv/icmp_socket.c
@@ -136,8 +136,8 @@ static ssize_t bat_socket_read(struct file *file, char __user *buf,
spin_unlock_bh(&socket_client->lock);
- error = __copy_to_user(buf, &socket_packet->icmp_packet,
- socket_packet->icmp_len);
+ error = copy_to_user(buf, &socket_packet->icmp_packet,
+ socket_packet->icmp_len);
packet_len = socket_packet->icmp_len;
kfree(socket_packet);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 04/11] batman-adv: check return value for hash_add()
From: Marek Lindner @ 2011-12-12 11:31 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Simon Wunderlich,
Marek Lindner
In-Reply-To: <1323689516-24427-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Simon Wunderlich <simon.wunderlich-Y4E02TeZ33kaBlGTGt4zH4SGEyLTKazZ@public.gmane.org>
if hash_add() fails, we should remove the structure to avoid memory
leaks.
Signed-off-by: Simon Wunderlich <siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX@public.gmane.org>
Acked-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Signed-off-by: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
---
net/batman-adv/translation-table.c | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index f6bbd64..cc87acf 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -190,6 +190,7 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr,
struct bat_priv *bat_priv = netdev_priv(soft_iface);
struct tt_local_entry *tt_local_entry = NULL;
struct tt_global_entry *tt_global_entry = NULL;
+ int hash_added;
tt_local_entry = tt_local_hash_find(bat_priv, addr);
@@ -217,6 +218,16 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr,
if (compare_eth(addr, soft_iface->dev_addr))
tt_local_entry->common.flags |= TT_CLIENT_NOPURGE;
+ hash_added = hash_add(bat_priv->tt_local_hash, compare_tt, choose_orig,
+ &tt_local_entry->common,
+ &tt_local_entry->common.hash_entry);
+
+ if (unlikely(hash_added != 0)) {
+ /* remove the reference for the hash */
+ tt_local_entry_free_ref(tt_local_entry);
+ goto out;
+ }
+
tt_local_event(bat_priv, addr, tt_local_entry->common.flags);
/* The local entry has to be marked as NEW to avoid to send it in
@@ -224,9 +235,6 @@ void tt_local_add(struct net_device *soft_iface, const uint8_t *addr,
* (consistency check) */
tt_local_entry->common.flags |= TT_CLIENT_NEW;
- hash_add(bat_priv->tt_local_hash, compare_tt, choose_orig,
- &tt_local_entry->common, &tt_local_entry->common.hash_entry);
-
/* remove address from global hash if present */
tt_global_entry = tt_global_hash_find(bat_priv, addr);
@@ -499,6 +507,7 @@ int tt_global_add(struct bat_priv *bat_priv, struct orig_node *orig_node,
struct tt_global_entry *tt_global_entry;
struct orig_node *orig_node_tmp;
int ret = 0;
+ int hash_added;
tt_global_entry = tt_global_hash_find(bat_priv, tt_addr);
@@ -518,9 +527,15 @@ int tt_global_add(struct bat_priv *bat_priv, struct orig_node *orig_node,
tt_global_entry->ttvn = ttvn;
tt_global_entry->roam_at = 0;
- hash_add(bat_priv->tt_global_hash, compare_tt,
- choose_orig, &tt_global_entry->common,
- &tt_global_entry->common.hash_entry);
+ hash_added = hash_add(bat_priv->tt_global_hash, compare_tt,
+ choose_orig, &tt_global_entry->common,
+ &tt_global_entry->common.hash_entry);
+
+ if (unlikely(hash_added != 0)) {
+ /* remove the reference for the hash */
+ tt_global_entry_free_ref(tt_global_entry);
+ goto out_remove;
+ }
atomic_inc(&orig_node->tt_size);
} else {
if (tt_global_entry->orig_node != orig_node) {
@@ -543,6 +558,7 @@ int tt_global_add(struct bat_priv *bat_priv, struct orig_node *orig_node,
"Creating new global tt entry: %pM (via %pM)\n",
tt_global_entry->common.addr, orig_node->orig);
+out_remove:
/* remove address from local hash if present */
tt_local_remove(bat_priv, tt_global_entry->common.addr,
"global tt received", roaming);
--
1.7.5.4
^ permalink raw reply related
* pull request: batman-adv 2011-12-12
From: Marek Lindner @ 2011-12-12 11:31 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Hi David,
here comes the next batch I'd like to get the pulled into net-next-2.6/3.3.
We have a couple of minor fixes for unregister_netdevice(), compat flags,
return value checks and a readme update. Plus the regression fix from Dan
that addresses a bug introduced with the previous batch. Security
researcher Paul Kot checked our kernelland / user space communication and
found a subtle bug which would make batman-adv write to memory locations
it should not write to. However, he did not find a way to exploit this
bug, therefore we classified it as "non-critical". Please let us know if
that is not ok with you.
Thanks,
Marek
The following changes since commit 76e8d7b0d1b0091929e8cd18551a87b6bb6ef2c1:
batman-adv: Fix range check for expected packets (2011-11-20 13:08:35 +0100)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git batman-adv/next
Antonio Quartulli (3):
batman-adv: create a common substructure for tt_global/local_entry
batman-adv: generalise tt_local_reset_flags()
batman-adv: format multi-line if in the correct way
Dan Carpenter (1):
batman-adv: remove extra negation in gw_out_of_range()
Marek Lindner (2):
batman-adv: report compat_version in version field in case of version mismatch
batman-adv: readme update (mention ap isolation and new log level)
Paul Kot (1):
batman-adv: bat_socket_read missing checks
Simon Wunderlich (2):
batman-adv: check return value for hash_add()
batman-adv: use unregister_netdevice() when softif_create fails
Sven Eckelmann (2):
batman-adv: Directly check read of icmp packet in copy_from_user
batman-adv: Only write requested number of byte to user buffer
Documentation/networking/batman-adv.txt | 7 +-
net/batman-adv/gateway_client.c | 2 +-
net/batman-adv/icmp_socket.c | 14 +-
net/batman-adv/routing.c | 3 +-
net/batman-adv/soft-interface.c | 2 +-
net/batman-adv/translation-table.c | 336 ++++++++++++++++++-------------
net/batman-adv/types.h | 14 +-
net/batman-adv/vis.c | 6 +-
8 files changed, 216 insertions(+), 168 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Zarre @ 2011-12-12 11:18 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, linux-can-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4EE5C824.2050704-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hello Wolfgang,
> Hi Wolfgang,
>
> On 12/11/2011 07:33 PM, Wolfgang Zarre wrote:
>> Hello Wolfgang,
>>> On 12/07/2011 02:42 PM, Wolfgang Grandegger wrote:
>>>> Hi Wolfgang,
>>>>
>>>> On 12/06/2011 10:08 PM, Wolfgang Zarre wrote:
> ...
>>>>> Let me know if You need more or some other tests.
>>>>
>>>> You could provoke some state changes or bus-off conditions to see if the
>>>> berr-counter shows reasonable results. I'm currently consolidating and
>>>> unifying error state and bus-off handling. Would be nice if you could do
>>>> some further tests when I have the patches ready...
>>>
>>> I just pushed the mentioned modifications to the "devel" branch of my
>>> "wg-linux-can-next" [1] repository. You can get it as shown below:
>>>
>>> $ git clone --reference=<some-recent-net-next-tree> \
>>> git://gitorious.org/~wgrandegger/linux-can/wg-linux-can-next.git
>>> $ git checkout -b devel devel
>>>
>>> [1] https://gitorious.org/~wgrandegger/linux-can/wg-linux-can-next
>>>
>>> Wolfgang.
>>
>> OK, I was trying so far and You will find below the results.
>> Just FYI the states on the PLC side couldn't be verified because the
>> function
>> provided by the manufacturer is not working at all and CAN analyser was not
>> available.
>>
>> We are running CANopen and therefore the PLC will send automatically a
>> heartbeat.
>>
>> I produced the bus-off state through a short circuit between L/H which was
>> working as expected.
>>
>> A bit odd was that on the second try I had to reload the module
>> because a ip down/up was not enough.
>
> Oops, not good.
>
But might be in connection with the strange behaviour of the PLC.
>> Let me know if You would need further tests or different procedure.
>
> The state changes are reported via error messages, which you can list
> with "candump -td -e any,0:0,#FFFFFFFF" with the attached patch.
>
Thanks, I'll try this with the next series of tests.
>> Producing L/H short circuit for 2 seconds
>> dmesg:
>> [ 885.409058] cc770_isa cc770_isa.0: can0: status interrupt (0x5b)
>> [ 885.420475] cc770_isa cc770_isa.0: can0: status interrupt (0xc5)
>> [ 885.420496] cc770_isa cc770_isa.0: can0: bus-off
>>
>> ip -d -s link show can0
>> 4: can0:<NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN
>> qlen 10
>> link/can
>> can state BUS-OFF (berr-counter tx 92 rx 103) restart-ms 0
>> bitrate 500000 sample-point 0.875
>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>> re-started bus-errors arbit-lost error-warn error-pass bus-off
>> 0 0 0 1 0 1
>> RX: bytes packets errors dropped overrun mcast
>> 544 382 0 0 0 0
>> TX: bytes packets errors dropped carrier collsns
>> 30 29 0 0 0 0
>>
>> Sending and receiving stops.
>>
>> Trying to recover on PC:
>> ip link set can0 down;
>> ip -d -s link show can0
>> 4: can0:<NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN qlen 10
>> link/can
>> can state STOPPED (berr-counter tx 92 rx 103) restart-ms 0
>> bitrate 500000 sample-point 0.875
>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>> re-started bus-errors arbit-lost error-warn error-pass bus-off
>> 0 0 0 1 0 1
>> RX: bytes packets errors dropped overrun mcast
>> 544 382 0 0 0 0
>> TX: bytes packets errors dropped carrier collsns
>> 30 29 0 1 0 0
>>
>> ip link set can0 up type can bitrate 500000;
>> dmesg:
>> [ 1090.937778] cc770_isa cc770_isa.0: can0: setting BTR0=0x00 BTR1=0x1c
>> [ 1090.937869] cc770_isa cc770_isa.0: can0: Message object 15 for RX
>> data, RTR, SFF and EFF
>> [ 1090.937885] cc770_isa cc770_isa.0: can0: Message object 11 for TX
>> data, RTR, SFF and EFF
>> [ 1090.938050] ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
>> [ 1090.940769] cc770_isa cc770_isa.0: can0: status interrupt (0x5)
>>
>> ip -d -s link show can0
>> 4: can0:<NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10
>> link/can
>> can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
>> bitrate 500000 sample-point 0.875
>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>> re-started bus-errors arbit-lost error-warn error-pass bus-off
>> 0 0 0 1 0 1
>> RX: bytes packets errors dropped overrun mcast
>> 552 383 0 0 0 0
>> TX: bytes packets errors dropped carrier collsns
>> 30 29 0 1 0 0
>>
>> PLC in unknown state but not sending heartbeat,
>> Rebooting PLC
>
> Hm, does it work if you do the bus-off recovery manually with?
>
> # ip link set can0 up type can restart
>
> ... or automatically with?
>
> # ip link set can0 up type can restart-ms 5000
Ah, ok, good point, will try out as well with the next series of tests
>
> Anyway, rebooting/reloading should never be necessary. I will check on
> my i82572.
>
>> -----------------------------------------
>> Disconnecting cable for around 4 seconds:
>>
>> dmesg:
>> [ 2339.660283] cc770_isa cc770_isa.0: can0: status interrupt (0x5b)
>>
>> ip -d -s link show can0
>> 6: can0:<NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>> qlen 10
>> link/can
>> can state ERROR-WARNING (berr-counter tx 128 rx 128) restart-ms 0
>> bitrate 500000 sample-point 0.875
>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>> re-started bus-errors arbit-lost error-warn error-pass bus-off
>> 0 0 0 1 0 0
>> RX: bytes packets errors dropped overrun mcast
>> 459 298 0 0 0 0
>> TX: bytes packets errors dropped carrier collsns
>> 193 192 0 0 0 0
>
> TX and RX berr-counter are>= 128. I wonder why error passive was not
> reached.
Hmmm, that is a good question and You are right > 127 should be error-passive,
anyway, just realised now, what means then 'error-warning' because I just
know error-active, error-passive and bus-off.
>
>> Connecting again:
>> ip -d -s link show can0
>> 6: can0:<NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>> qlen 10
>> link/can
>> can state ERROR-WARNING (berr-counter tx 120 rx 0) restart-ms 0
>> bitrate 500000 sample-point 0.875
>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>> re-started bus-errors arbit-lost error-warn error-pass bus-off
>> 0 0 0 1 0 0
>> RX: bytes packets errors dropped overrun mcast
>> 473 311 0 0 0 0
>> TX: bytes packets errors dropped carrier collsns
>> 200 200 0 0 0 0
>>
>> After some time (around 125 seconds):
>> dmesg:
>> [ 2387.172008] cc770_isa cc770_isa.0: can0: status interrupt (0x18)
>> ip -d -s link show can0
>> 6: can0:<NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
>> qlen 10
>> link/can
>> can state ERROR-ACTIVE (berr-counter tx 29 rx 0) restart-ms 0
>> bitrate 500000 sample-point 0.875
>> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
>> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>> clock 8000000
>> re-started bus-errors arbit-lost error-warn error-pass bus-off
>> 0 0 0 1 0 0
>> RX: bytes packets errors dropped overrun mcast
>> 616 447 0 0 0 0
>> TX: bytes packets errors dropped carrier collsns
>> 291 291 0 0 0 0
>
> OK, the state is back to error active (counter< 96).
>
> Thanks for testing...
You are welcome, however, I have to thank You for Your work done.
So, I'll try as soon as I can another series of tests and may be
You let me know if You have patches I should include as well.
>
> Wolfgang.
>
>
>
Thanks
Wolfgang
^ permalink raw reply
* Re: [PATCH net-next] can: plx_pci: add support for IXXAT PCI cards
From: Wolfgang Grandegger @ 2011-12-12 11:02 UTC (permalink / raw)
To: kime; +Cc: linux-can, netdev, socketcan-core
In-Reply-To: <166589D0B9DD2547A1319599B9BADA1FC62431@vsv-exchange.ixxat.intranet.priv>
On 12/12/2011 11:44 AM, kime@ixxat.de wrote:
> This patch adds support for IXXAT passive CAN controllers
>
> Signed-off-by: James Kime <kime@ixxat.de>
I cannot apply this patch. git am reports:
Applying: can: plx_pci: add support for IXXAT PCI cards
fatal: corrupt patch at line 30
That's because lines are wrapped, I believe. And could you please update
the Kconfig entry as well?
Thanks,
Wolfgang.
^ permalink raw reply
* [PATCH net-next] can: plx_pci: add support for IXXAT PCI cards
From: kime-Z4QKGCRq86k @ 2011-12-12 10:44 UTC (permalink / raw)
To: linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w
This patch adds support for IXXAT passive CAN controllers
Signed-off-by: James Kime <kime-Z4QKGCRq86k@public.gmane.org>
---
diff --git a/drivers/net/can/sja1000/plx_pci.c
b/drivers/net/can/sja1000/plx_pci.c
index 231385b..a0c693a 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -43,7 +43,8 @@ MODULE_SUPPORTED_DEVICE("Adlink PCI-7841/cPCI-7841, "
"TEWS TECHNOLOGIES TPMC810, "
"esd CAN-PCI/CPCI/PCI104/200, "
"esd CAN-PCI/PMC/266, "
- "esd CAN-PCIe/2000")
+ "esd CAN-PCIe/2000, "
+ "IXXAT PC-I 04/PCI")
MODULE_LICENSE("GPL v2");
#define PLX_PCI_MAX_CHAN 2
@@ -121,6 +122,10 @@ struct plx_pci_card {
#define ESD_PCI_SUB_SYS_ID_PCIE2000 0x0200
#define ESD_PCI_SUB_SYS_ID_PCI104200 0x0501
+#define IXXAT_PCI_VENDOR_ID 0x10b5
+#define IXXAT_PCI_DEVICE_ID 0x9050
+#define IXXAT_PCI_SUB_SYS_ID 0x2540
+
#define MARATHON_PCI_DEVICE_ID 0x2715
#define TEWS_PCI_VENDOR_ID 0x1498
@@ -193,6 +198,14 @@ static struct plx_pci_card_info
plx_pci_card_info_esd2000 __devinitdata = {
/* based on PEX8311 */
};
+static struct plx_pci_card_info plx_pci_card_info_ixxat __devinitdata =
{
+ "IXXAT PC-I 04/PCI", 2,
+ PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
+ {0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x200, 0x80} },
+ &plx_pci_reset_common
+ /* based on PLX9050 */
+};
+
static struct plx_pci_card_info plx_pci_card_info_marathon
__devinitdata = {
"Marathon CAN-bus-PCI", 2,
PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
@@ -267,6 +280,13 @@ static DEFINE_PCI_DEVICE_TABLE(plx_pci_tbl) = {
(kernel_ulong_t)&plx_pci_card_info_esd2000
},
{
+ /* IXXAT PC-I 04/PCI card */
+ IXXAT_PCI_VENDOR_ID, IXXAT_PCI_DEVICE_ID,
+ PCI_ANY_ID, IXXAT_PCI_SUB_SYS_ID,
+ 0, 0,
+ (kernel_ulong_t)&plx_pci_card_info_ixxat
+ },
+ {
/* Marathon CAN-bus-PCI card */
PCI_VENDOR_ID_PLX, MARATHON_PCI_DEVICE_ID,
PCI_ANY_ID, PCI_ANY_ID,
^ permalink raw reply related
* [PATCH 1/1] net/fec: add KSZ9021RN phy fixup
From: Richard Zhao @ 2011-12-12 10:09 UTC (permalink / raw)
To: netdev
Cc: linux-arm-kernel, davem, shawn.guo, jgq516, eric.miao, patches,
Richard Zhao
For imx6q sabrelite board, set phy RGMII pad skew.
Signed-off-by: Richard Zhao <richard.zhao@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 112af9b..d3b4463 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1513,6 +1513,21 @@ static inline void fec_reset_phy(struct platform_device *pdev)
}
#endif /* CONFIG_OF */
+/* For imx6q sabrelite board: set KSZ9021RN RGMII pad skew */
+static int ksz9021rn_phy_fixup(struct phy_device *phydev)
+{
+ /* min rx data delay */
+ phy_write(phydev, 0x0b, 0x8105);
+ phy_write(phydev, 0x0c, 0x0000);
+
+ /* max rx/tx clock delay, min rx/tx control delay */
+ phy_write(phydev, 0x0b, 0x8104);
+ phy_write(phydev, 0x0c, 0xf0f0);
+ phy_write(phydev, 0x0b, 0x104);
+
+ return 0;
+}
+
static int __devinit
fec_probe(struct platform_device *pdev)
{
@@ -1597,6 +1612,10 @@ fec_probe(struct platform_device *pdev)
if (ret)
goto failed_init;
+ /* register the PHY board fixup (for Micrel KSZ9021RN) */
+ phy_register_fixup_for_uid(0x00221611, 0xfffffff0,
+ ksz9021rn_phy_fixup);
+
ret = fec_enet_mii_init(pdev);
if (ret)
goto failed_mii_init;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] pch_can: fix error passive level test
From: Wolfgang Grandegger @ 2011-12-12 9:50 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Xi Wang, Masayuki Ohtake, Tomoya MORINAGA, linux-can, netdev,
David S. Miller
In-Reply-To: <4EE5CBBD.4050206@pengutronix.de>
On 12/12/2011 10:39 AM, Marc Kleine-Budde wrote:
> On 12/12/2011 10:31 AM, Wolfgang Grandegger wrote:
>> On 12/12/2011 10:17 AM, Marc Kleine-Budde wrote:
>>> On 12/12/2011 09:05 AM, Wolfgang Grandegger wrote:
>>>> On 12/12/2011 08:16 AM, Xi Wang wrote:
>>>>> The test (((errc & PCH_REC) >> 8) > 127) would always be false because
>>>>> the receive error counter ((errc & PCH_REC) >> 8) is at most 127, where
>>>>> PCH_REC is defined as 0x7f00. To test whether the receive error counter
>>>>> has reached the error passive level, the RP bit (15) should be used.
>>>>>
>>>>> Signed-off-by: Xi Wang <xi.wang@gmail.com>
>>>>
>>>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
>>>
>>> Is this patch a candidate for stable?
>>
>> You mean for the "net" branch? Yes, I think so.
>
> Even for all trees which contain this driver (in a working version),
> which is v2.6.38 and newer.
OK, Well, it's not a serious fix, at least.
Wolfgang.
^ permalink raw reply
* Re: Testing server performance
From: Igor Maravić @ 2011-12-12 9:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1323682612.2948.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
> I have doubts you get such poor performance from your machine.
>
> 77Mbps, thats how many packets per second ???
>
I've got 77MBps not 77Mbps. :)
I was testing with packets of length 1024B
That's about 80000 packets/s
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c
From: Stefan Priebe - Profihost AG @ 2011-12-12 9:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Josh Boyer, Christoph Hellwig, netdev, Dave Chinner, stable
In-Reply-To: <4ED86B79.4060506@profihost.ag>
Hi,
> Am 01.12.2011 22:05, schrieb Eric Dumazet:
>> Le jeudi 01 décembre 2011 à 15:37 -0500, Josh Boyer a écrit :
>>
>>> Did you mean f2c31e32bf2c31e32b378a665 ?
>>
>> Oh well, yes ;)
>>
>>>> But this patch needs some followup patches (some of them in David net
>>>> tree, not yet in Linus tree)
>>>
>>> 9de79c127cccecb11ae6a21ab1499e87aa222880 (net: fix potential neighbour
>>> race in dst_ifdown()) is in Linus' tree. Which others are missing?
>>
>> Hmm
>>
>> Linus tree :
>>
>> commit 580da35a31f91a594f3090b7a2c39b85cb051a12
>> IB: Fix RCU lockdep splats
>>
>> David tree :
>>
>> commit 218fa90f072e4aeff9003d57e390857f4f35513e
>> ipv4: fix lockdep splat in rt_cache_seq_show
>>
>> commit f7e57044eeb1841847c24aa06766c8290c202583
>> sch_teql: fix lockdep splat
main problem seems to me that all these patches make intensive use of
the "new" helper functions from 69cce1d1404968f78b177a0314f5822d5afdbbfb
So must 69cce1d1404968f78b177a0314f5822d5afdbbfb be backported too?
Stefan
^ permalink raw reply
* [PATCH] sch_gred: should not use GFP_KERNEL while holding a spinlock
From: Eric Dumazet @ 2011-12-12 9:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev
gred_change_vq() is called under sch_tree_lock(sch).
This means a spinlock is held, and we are not allowed to sleep in this
context.
We might pre-allocate memory using GFP_KERNEL before taking spinlock,
but this is not suitable for stable material.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_gred.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index b9493a0..6cd8ddf 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -385,7 +385,7 @@ static inline int gred_change_vq(struct Qdisc *sch, int dp,
struct gred_sched_data *q;
if (table->tab[dp] == NULL) {
- table->tab[dp] = kzalloc(sizeof(*q), GFP_KERNEL);
+ table->tab[dp] = kzalloc(sizeof(*q), GFP_ATOMIC);
if (table->tab[dp] == NULL)
return -ENOMEM;
}
^ permalink raw reply related
* Re: [PATCH] pch_can: fix error passive level test
From: Marc Kleine-Budde @ 2011-12-12 9:39 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Xi Wang, Masayuki Ohtake, Tomoya MORINAGA, linux-can, netdev,
David S. Miller
In-Reply-To: <4EE5C9F2.7050502@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
On 12/12/2011 10:31 AM, Wolfgang Grandegger wrote:
> On 12/12/2011 10:17 AM, Marc Kleine-Budde wrote:
>> On 12/12/2011 09:05 AM, Wolfgang Grandegger wrote:
>>> On 12/12/2011 08:16 AM, Xi Wang wrote:
>>>> The test (((errc & PCH_REC) >> 8) > 127) would always be false because
>>>> the receive error counter ((errc & PCH_REC) >> 8) is at most 127, where
>>>> PCH_REC is defined as 0x7f00. To test whether the receive error counter
>>>> has reached the error passive level, the RP bit (15) should be used.
>>>>
>>>> Signed-off-by: Xi Wang <xi.wang@gmail.com>
>>>
>>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
>>
>> Is this patch a candidate for stable?
>
> You mean for the "net" branch? Yes, I think so.
Even for all trees which contain this driver (in a working version),
which is v2.6.38 and newer.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: Testing server performance
From: Eric Dumazet @ 2011-12-12 9:36 UTC (permalink / raw)
To: igorm; +Cc: netdev
In-Reply-To: <CAFdo_mW0sKSZp3L75BOPBN1Sa+ZQ8WiBRC98eFLM5BaxCVrpJQ@mail.gmail.com>
Le vendredi 09 décembre 2011 à 16:26 +0100, Igor Maravić a écrit :
> Hi all,
> I'm currently testing how much traffic can I push through my server.
> I'm running on Ubuntu 11.10 server with net-next kernel.
> I'm using 2 Gbps NICs, Netgear GA311 and D-Link DGE-528T, that use r8169 driver.
> I'm generating UDP packets from a router with constant speed.
>
> After I push traffic to my server with max speed, it saturates.
> It receives packets at 77MBps and it sends packet with 14MBps.
> When there are no incoming traffic, but there are remaining packets in
> tx fifo queue, it sends them with 40MBps.
>
> That all wouldn't be strange because my machine isn't any thing special
> (AMD Athlon(tm) II X2 240 on 2,8GHz, motherboard ASUS M2N68 PLUS and
> 2x2GB DDR2 RAM memory on 1066MHz),
> but the dstat shows that CPUs are maximally using 6% of their
> resources for interrupt handling.
> Beside that, nothing else is using CPU time.
> Why does it saturate on this values then? Am I doing something wrong?
> Any help is appreciated.
>
> BR
> Igor
>
> PS. Kernel is SMP enabled and I tried different bit masks for
> smp_affinity for my interfaces, but I still got the same result.
I have doubts you get such poor performance from your machine.
77Mbps, thats how many packets per second ???
^ permalink raw reply
* Re: [PATCH] pch_can: fix error passive level test
From: Wolfgang Grandegger @ 2011-12-12 9:31 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Xi Wang, Masayuki Ohtake, Tomoya MORINAGA, linux-can, netdev,
David S. Miller
In-Reply-To: <4EE5C6A7.1070506@pengutronix.de>
On 12/12/2011 10:17 AM, Marc Kleine-Budde wrote:
> On 12/12/2011 09:05 AM, Wolfgang Grandegger wrote:
>> On 12/12/2011 08:16 AM, Xi Wang wrote:
>>> The test (((errc & PCH_REC) >> 8) > 127) would always be false because
>>> the receive error counter ((errc & PCH_REC) >> 8) is at most 127, where
>>> PCH_REC is defined as 0x7f00. To test whether the receive error counter
>>> has reached the error passive level, the RP bit (15) should be used.
>>>
>>> Signed-off-by: Xi Wang <xi.wang@gmail.com>
>>
>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
>
> Is this patch a candidate for stable?
You mean for the "net" branch? Yes, I think so.
Wolfgang.
^ permalink raw reply
* Re: Testing server performance
From: Igor Maravić @ 2011-12-12 9:24 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4EE242DF.2000609@candelatech.com>
> Check the bus speed and width on your NICs. dmesg usually shows this
> info when the interfaces are first detected.
>
> If you can, try some Intel NICs..they will usually run wire speed
> if the motherboard is reasonably fast.
>
> Thanks,
> Ben
Thanks for the advice.
I' ll see if I can find some Intel NICs.
NIC's specs says that they support 32-bit 33/66MHz clock speed PCI Bus
Master operation.
Should that be enough?
I'll see what dmesg showed tomorow, because I'm not at my computer currently.
BR
Igor
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Grandegger @ 2011-12-12 9:23 UTC (permalink / raw)
To: info-PyqsHJVlJN8AvxtiuMwx3w
Cc: Oliver Hartkopp, linux-can-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4EE4F76E.3000506-PyqsHJVlJN8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 7671 bytes --]
Hi Wolfgang,
On 12/11/2011 07:33 PM, Wolfgang Zarre wrote:
> Hello Wolfgang,
>> On 12/07/2011 02:42 PM, Wolfgang Grandegger wrote:
>>> Hi Wolfgang,
>>>
>>> On 12/06/2011 10:08 PM, Wolfgang Zarre wrote:
...
>>>> Let me know if You need more or some other tests.
>>>
>>> You could provoke some state changes or bus-off conditions to see if the
>>> berr-counter shows reasonable results. I'm currently consolidating and
>>> unifying error state and bus-off handling. Would be nice if you could do
>>> some further tests when I have the patches ready...
>>
>> I just pushed the mentioned modifications to the "devel" branch of my
>> "wg-linux-can-next" [1] repository. You can get it as shown below:
>>
>> $ git clone --reference=<some-recent-net-next-tree> \
>> git://gitorious.org/~wgrandegger/linux-can/wg-linux-can-next.git
>> $ git checkout -b devel devel
>>
>> [1] https://gitorious.org/~wgrandegger/linux-can/wg-linux-can-next
>>
>> Wolfgang.
>
> OK, I was trying so far and You will find below the results.
> Just FYI the states on the PLC side couldn't be verified because the
> function
> provided by the manufacturer is not working at all and CAN analyser was not
> available.
>
> We are running CANopen and therefore the PLC will send automatically a
> heartbeat.
>
> I produced the bus-off state through a short circuit between L/H which was
> working as expected.
>
> A bit odd was that on the second try I had to reload the module
> because a ip down/up was not enough.
Oops, not good.
> Let me know if You would need further tests or different procedure.
The state changes are reported via error messages, which you can list
with "candump -td -e any,0:0,#FFFFFFFF" with the attached patch.
> Producing L/H short circuit for 2 seconds
> dmesg:
> [ 885.409058] cc770_isa cc770_isa.0: can0: status interrupt (0x5b)
> [ 885.420475] cc770_isa cc770_isa.0: can0: status interrupt (0xc5)
> [ 885.420496] cc770_isa cc770_isa.0: can0: bus-off
>
> ip -d -s link show can0
> 4: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN
> qlen 10
> link/can
> can state BUS-OFF (berr-counter tx 92 rx 103) restart-ms 0
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 1 0 1
> RX: bytes packets errors dropped overrun mcast
> 544 382 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 30 29 0 0 0 0
>
> Sending and receiving stops.
>
> Trying to recover on PC:
> ip link set can0 down;
> ip -d -s link show can0
> 4: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN qlen 10
> link/can
> can state STOPPED (berr-counter tx 92 rx 103) restart-ms 0
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 1 0 1
> RX: bytes packets errors dropped overrun mcast
> 544 382 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 30 29 0 1 0 0
>
> ip link set can0 up type can bitrate 500000;
> dmesg:
> [ 1090.937778] cc770_isa cc770_isa.0: can0: setting BTR0=0x00 BTR1=0x1c
> [ 1090.937869] cc770_isa cc770_isa.0: can0: Message object 15 for RX
> data, RTR, SFF and EFF
> [ 1090.937885] cc770_isa cc770_isa.0: can0: Message object 11 for TX
> data, RTR, SFF and EFF
> [ 1090.938050] ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
> [ 1090.940769] cc770_isa cc770_isa.0: can0: status interrupt (0x5)
>
> ip -d -s link show can0
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10
> link/can
> can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 1 0 1
> RX: bytes packets errors dropped overrun mcast
> 552 383 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 30 29 0 1 0 0
>
> PLC in unknown state but not sending heartbeat,
> Rebooting PLC
Hm, does it work if you do the bus-off recovery manually with?
# ip link set can0 up type can restart
... or automatically with?
# ip link set can0 up type can restart-ms 5000
Anyway, rebooting/reloading should never be necessary. I will check on
my i82572.
> -----------------------------------------
> Disconnecting cable for around 4 seconds:
>
> dmesg:
> [ 2339.660283] cc770_isa cc770_isa.0: can0: status interrupt (0x5b)
>
> ip -d -s link show can0
> 6: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> qlen 10
> link/can
> can state ERROR-WARNING (berr-counter tx 128 rx 128) restart-ms 0
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 1 0 0
> RX: bytes packets errors dropped overrun mcast
> 459 298 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 193 192 0 0 0 0
TX and RX berr-counter are >= 128. I wonder why error passive was not
reached.
> Connecting again:
> ip -d -s link show can0
> 6: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> qlen 10
> link/can
> can state ERROR-WARNING (berr-counter tx 120 rx 0) restart-ms 0
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 1 0 0
> RX: bytes packets errors dropped overrun mcast
> 473 311 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 200 200 0 0 0 0
>
> After some time (around 125 seconds):
> dmesg:
> [ 2387.172008] cc770_isa cc770_isa.0: can0: status interrupt (0x18)
> ip -d -s link show can0
> 6: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> qlen 10
> link/can
> can state ERROR-ACTIVE (berr-counter tx 29 rx 0) restart-ms 0
> bitrate 500000 sample-point 0.875
> tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> cc770: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 1 0 0
> RX: bytes packets errors dropped overrun mcast
> 616 447 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 291 291 0 0 0 0
OK, the state is back to error active (counter < 96).
Thanks for testing...
Wolfgang.
[-- Attachment #2: 0001-candump-add-support-for-error-states-going-backward.patch --]
[-- Type: text/x-diff, Size: 1299 bytes --]
>From e7b36500c9491ab026bd3c16dfca2ca4338524ac Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Date: Mon, 12 Dec 2011 10:09:22 +0100
Subject: [PATCH] candump: add support for error states going backward
Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
lib.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/lib.c b/lib.c
index a8ed2fe..7f810b9 100644
--- a/lib.c
+++ b/lib.c
@@ -318,6 +318,7 @@ static const char *error_classes[] = {
"bus-off",
"bus-error",
"restarted-after-bus-off",
+ "state-change",
};
static const char *controller_problems[] = {
@@ -327,6 +328,7 @@ static const char *controller_problems[] = {
"tx-error-warning",
"rx-error-passive",
"tx-error-passive",
+ "back-to-error-active",
};
static const char *protocol_violation_types[] = {
@@ -471,6 +473,8 @@ void snprintf_can_error_frame(char *buf, size_t len, struct can_frame *cf,
if (mask == CAN_ERR_LOSTARB)
n += snprintf_error_lostarb(buf + n, len - n,
cf);
+ if (mask == CAN_ERR_STATE_CHANGE)
+ n += snprintf_error_ctrl(buf + n, len - n, cf);
if (mask == CAN_ERR_CRTL)
n += snprintf_error_ctrl(buf + n, len - n, cf);
if (mask == CAN_ERR_PROT)
--
1.7.4.1
[-- Attachment #3: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply related
* Re: [PATCH] pch_can: fix error passive level test
From: Marc Kleine-Budde @ 2011-12-12 9:17 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Xi Wang, Masayuki Ohtake, Tomoya MORINAGA, linux-can, netdev,
David S. Miller
In-Reply-To: <4EE5B5D9.3030702@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
On 12/12/2011 09:05 AM, Wolfgang Grandegger wrote:
> On 12/12/2011 08:16 AM, Xi Wang wrote:
>> The test (((errc & PCH_REC) >> 8) > 127) would always be false because
>> the receive error counter ((errc & PCH_REC) >> 8) is at most 127, where
>> PCH_REC is defined as 0x7f00. To test whether the receive error counter
>> has reached the error passive level, the RP bit (15) should be used.
>>
>> Signed-off-by: Xi Wang <xi.wang@gmail.com>
>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Is this patch a candidate for stable?
> The C_CAN driver, which supports the same CAN controller, does handle
> the error passive state correctly. This reminds me to get rid of pch_can
> in favor of C_CAN sooner than later.
+1
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* the linux-can-next tree (was: Re: [PATCH next-next 0/2] can: cc770: add support for the Bosch CC770 and Intel AN82527)
From: Marc Kleine-Budde @ 2011-12-12 9:13 UTC (permalink / raw)
To: David Miller; +Cc: socketcan, wg, netdev, linux-can, urs
In-Reply-To: <4ED7DDBA.9090201@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hello David,
On 12/01/2011 09:04 PM, Marc Kleine-Budde wrote:
>> I said I want one person. One person who periodically send me GIT pull requests
>> or a patch series for "CAN updates" of all kinds.
>
> We're currently discussing the problem and we understood the one person
> contact policy.
We decided that I should be this person. Our can tree is located on
gitorious:
https://gitorious.org/linux-can/linux-can-next
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH] pch_can: fix error passive level test
From: Wolfgang Grandegger @ 2011-12-12 8:05 UTC (permalink / raw)
To: Xi Wang
Cc: Masayuki Ohtake, Tomoya MORINAGA, linux-can, netdev,
David S. Miller
In-Reply-To: <1323674180-16916-1-git-send-email-xi.wang@gmail.com>
On 12/12/2011 08:16 AM, Xi Wang wrote:
> The test (((errc & PCH_REC) >> 8) > 127) would always be false because
> the receive error counter ((errc & PCH_REC) >> 8) is at most 127, where
> PCH_REC is defined as 0x7f00. To test whether the receive error counter
> has reached the error passive level, the RP bit (15) should be used.
>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
The C_CAN driver, which supports the same CAN controller, does handle
the error passive state correctly. This reminds me to get rid of pch_can
in favor of C_CAN sooner than later.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: vmxnet3 driver broken since 3.0?
From: Alessandro Salvatori @ 2011-12-12 7:54 UTC (permalink / raw)
To: Zbigniew Luszpinski; +Cc: netdev
In-Reply-To: <loom.20111211T232956-373@post.gmane.org>
I guess this is the change that was introduced in 3.0 and that breaks vmxnet3:
commit 55513fb4281464e97aa1ff2b9c906ca5aed917c5
Author: Tom Herbert <therbert@google.com>
Date: Mon Oct 18 17:55:58 2010 +0000
net: fail alloc_netdev_mq if queue count < 1
In alloc_netdev_mq fail if requested queue_count < 1.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/core/dev.c b/net/core/dev.c
index 04972a4..f44d29a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5511,6 +5511,12 @@ struct net_device *alloc_netdev_mq(int
sizeof_priv, const char *name,
BUG_ON(strlen(name) >= sizeof(dev->name));
+ if (queue_count < 1) {
+ pr_err("alloc_netdev: Unable to allocate device "
+ "with zero queues.\n");
+ return NULL;
+ }
+
alloc_size = sizeof(struct net_device);
if (sizeof_priv) {
/* ensure 32-byte alignment of private area */
thanks!
-Alessandro-
Here i am, A young man,
A crashing computer program,
Here is a pen, write out my name...
(from: The Servant - Orchestra)
On Sun, Dec 11, 2011 at 14:38, Zbigniew Luszpinski <zbiggy@o2.pl> wrote:
> Alessandro Salvatori <sandr8 <at> gmail.com> writes:
>> haven't had a chance to try the one from the 3.2 release candidates yet.
>
> In 3.2-rc5 is still broken. Exactly the same error you get. :(
> Someone introduced a change since kernel 3.0 which broke vmxnet3 driver. And
> this breaking change continues in kernel 3.1 and 3.2-rc5 so it seems it will not
> go away. :(
>
> have a nice day,
> Zbigniew Luszpinski
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v9 9/9] Display maximum tcp memory allocation in kmem cgroup
From: Glauber Costa @ 2011-12-12 7:47 UTC (permalink / raw)
To: davem
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups,
Glauber Costa
In-Reply-To: <1323676029-5890-1-git-send-email-glommer@parallels.com>
This patch introduces kmem.tcp.max_usage_in_bytes file, living in the
kmem_cgroup filesystem. The root cgroup will display a value equal
to RESOURCE_MAX. This is to avoid introducing any locking schemes in
the network paths when cgroups are not being actively used.
All others, will see the maximum memory ever used by this cgroup.
Signed-off-by: Glauber Costa <glommer@parallels.com>
Reviewed-by: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
net/ipv4/tcp_memcontrol.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index d438fba..171d7b6 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -29,6 +29,12 @@ static struct cftype tcp_files[] = {
.trigger = tcp_cgroup_reset,
.read_u64 = tcp_cgroup_read,
},
+ {
+ .name = "kmem.tcp.max_usage_in_bytes",
+ .private = RES_MAX_USAGE,
+ .trigger = tcp_cgroup_reset,
+ .read_u64 = tcp_cgroup_read,
+ },
};
static inline struct tcp_memcontrol *tcp_from_cgproto(struct cg_proto *cg_proto)
@@ -205,7 +211,8 @@ static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft)
val = tcp_read_usage(memcg);
break;
case RES_FAILCNT:
- val = tcp_read_stat(memcg, RES_FAILCNT, 0);
+ case RES_MAX_USAGE:
+ val = tcp_read_stat(memcg, cft->private, 0);
break;
default:
BUG();
@@ -226,6 +233,9 @@ static int tcp_cgroup_reset(struct cgroup *cont, unsigned int event)
tcp = tcp_from_cgproto(cg_proto);
switch (event) {
+ case RES_MAX_USAGE:
+ res_counter_reset_max(&tcp->tcp_memory_allocated);
+ break;
case RES_FAILCNT:
res_counter_reset_failcnt(&tcp->tcp_memory_allocated);
break;
--
1.7.6.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v9 8/9] Display current tcp failcnt in kmem cgroup
From: Glauber Costa @ 2011-12-12 7:47 UTC (permalink / raw)
To: davem
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups,
Glauber Costa
In-Reply-To: <1323676029-5890-1-git-send-email-glommer@parallels.com>
This patch introduces kmem.tcp.failcnt file, living in the
kmem_cgroup filesystem. Following the pattern in the other
memcg resources, this files keeps a counter of how many times
allocation failed due to limits being hit in this cgroup.
The root cgroup will always show a failcnt of 0.
Signed-off-by: Glauber Costa <glommer@parallels.com>
Reviewed-by: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
net/ipv4/tcp_memcontrol.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index 9481f23..d438fba 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -9,6 +9,7 @@
static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft);
static int tcp_cgroup_write(struct cgroup *cont, struct cftype *cft,
const char *buffer);
+static int tcp_cgroup_reset(struct cgroup *cont, unsigned int event);
static struct cftype tcp_files[] = {
{
@@ -22,6 +23,12 @@ static struct cftype tcp_files[] = {
.read_u64 = tcp_cgroup_read,
.private = RES_USAGE,
},
+ {
+ .name = "kmem.tcp.failcnt",
+ .private = RES_FAILCNT,
+ .trigger = tcp_cgroup_reset,
+ .read_u64 = tcp_cgroup_read,
+ },
};
static inline struct tcp_memcontrol *tcp_from_cgproto(struct cg_proto *cg_proto)
@@ -197,12 +204,36 @@ static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft)
case RES_USAGE:
val = tcp_read_usage(memcg);
break;
+ case RES_FAILCNT:
+ val = tcp_read_stat(memcg, RES_FAILCNT, 0);
+ break;
default:
BUG();
}
return val;
}
+static int tcp_cgroup_reset(struct cgroup *cont, unsigned int event)
+{
+ struct mem_cgroup *memcg;
+ struct tcp_memcontrol *tcp;
+ struct cg_proto *cg_proto;
+
+ memcg = mem_cgroup_from_cont(cont);
+ cg_proto = tcp_prot.proto_cgroup(memcg);
+ if (!cg_proto)
+ return 0;
+ tcp = tcp_from_cgproto(cg_proto);
+
+ switch (event) {
+ case RES_FAILCNT:
+ res_counter_reset_failcnt(&tcp->tcp_memory_allocated);
+ break;
+ }
+
+ return 0;
+}
+
unsigned long long tcp_max_memory(const struct mem_cgroup *memcg)
{
struct tcp_memcontrol *tcp;
--
1.7.6.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v9 7/9] Display current tcp memory allocation in kmem cgroup
From: Glauber Costa @ 2011-12-12 7:47 UTC (permalink / raw)
To: davem
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups,
Glauber Costa
In-Reply-To: <1323676029-5890-1-git-send-email-glommer@parallels.com>
This patch introduces kmem.tcp.usage_in_bytes file, living in the
kmem_cgroup filesystem. It is a simple read-only file that displays the
amount of kernel memory currently consumed by the cgroup.
Signed-off-by: Glauber Costa <glommer@parallels.com>
Reviewed-by: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: David S. Miller <davem@davemloft.net>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
Documentation/cgroups/memory.txt | 1 +
net/ipv4/tcp_memcontrol.c | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 1c9779a..6922b6c 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -79,6 +79,7 @@ Brief summary of control files.
memory.independent_kmem_limit # select whether or not kernel memory limits are
independent of user limits
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
+ memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
1. History
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index e353390..9481f23 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -17,6 +17,11 @@ static struct cftype tcp_files[] = {
.read_u64 = tcp_cgroup_read,
.private = RES_LIMIT,
},
+ {
+ .name = "kmem.tcp.usage_in_bytes",
+ .read_u64 = tcp_cgroup_read,
+ .private = RES_USAGE,
+ },
};
static inline struct tcp_memcontrol *tcp_from_cgproto(struct cg_proto *cg_proto)
@@ -167,6 +172,19 @@ static u64 tcp_read_stat(struct mem_cgroup *memcg, int type, u64 default_val)
return res_counter_read_u64(&tcp->tcp_memory_allocated, type);
}
+static u64 tcp_read_usage(struct mem_cgroup *memcg)
+{
+ struct tcp_memcontrol *tcp;
+ struct cg_proto *cg_proto;
+
+ cg_proto = tcp_prot.proto_cgroup(memcg);
+ if (!cg_proto)
+ return atomic_long_read(&tcp_memory_allocated) << PAGE_SHIFT;
+
+ tcp = tcp_from_cgproto(cg_proto);
+ return res_counter_read_u64(&tcp->tcp_memory_allocated, RES_USAGE);
+}
+
static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft)
{
struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
@@ -176,6 +194,9 @@ static u64 tcp_cgroup_read(struct cgroup *cont, struct cftype *cft)
case RES_LIMIT:
val = tcp_read_stat(memcg, RES_LIMIT, RESOURCE_MAX);
break;
+ case RES_USAGE:
+ val = tcp_read_usage(memcg);
+ break;
default:
BUG();
}
--
1.7.6.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
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