* forcedeth: cat /sys/class/net/eth0/carrier = Invalid argument
From: Justin P. mattock @ 2010-03-22 17:36 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel Mailing List
I've pushed my kernel from the latest HEAD to 2.6.31
and am still seeing:
cat /sys/class/net/eth0/carrier
cat: carrier: Invalid argument
with my other machine using sky2
the same results is:
cat /sys/class/net/eth0/carrier
0
is there anything on this? before I start
a bisect.(looking through bugzilla, I couldn't
see anything related).
Justin P. Mattock
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Jiri Pirko @ 2010-03-22 17:26 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: netdev, davem, ogerlitz, linux-rdma, monis
In-Reply-To: <20100322165916.GE29129@obsidianresearch.com>
Mon, Mar 22, 2010 at 05:59:16PM CET, jgunthorpe@obsidianresearch.com wrote:
>On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
>> Finally this bit can be removed. Currently, after the bonding driver is
>> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
>> that's not possible for an addr with different length than dev->addr_len
>> to be present in list. Removing this check as in new mc_list there will be
>> no addrlen in the record.
>
>Maybe just make this check a WARN_ON?
As I said, addrlen will no longer be in record (because it would have no
meaning since length ot the addr is always dev->addr_len)
>Can userspace create a mc_list
>entry with the wrong size via netlink?
Nope - this is not possible. dev->addr_len is used.
>
>Jason
^ permalink raw reply
* Re: Gianfar: RX Recycle skb->len error
From: Anton Vorontsov @ 2010-03-22 17:24 UTC (permalink / raw)
To: David Miller; +Cc: ben, netdev, Sandeep.Kumar
In-Reply-To: <20100321.214642.67901344.davem@davemloft.net>
On Sun, Mar 21, 2010 at 09:46:42PM -0700, David Miller wrote:
[...]
> > * recycle list.
> > */
> > skb->data = skb->head + NET_SKB_PAD;
> > + skb_reset_tail_pointer(skb);
> > __skb_queue_head(&priv->rx_recycle, skb);
> > }
> > } else {
>
> This code is essentially trying to undo skb_reserve()
> but as you found it's doing so in a buggy manner.
>
> skb_reserve() adjusts both the 'data' and 'tail' pointers,
> but this attempt at a reversal is only modifying 'data'.
>
> Your fix is fine, but really any by-hand modification of
> skb->data is a bug, and we should provide an skb_unreserve()
> or similar to hide such details away, and use it here.
>
> Anton?
Yes, skb_unreserve() (or skb_reset_reserved() for naming consistency?)
would be great.
Ben, note that ucc_geth.c driver is also affected by that bug,
so I guess it needs a similar fix.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] rxrpc: Check allocation failure.
From: David Miller @ 2010-03-22 17:23 UTC (permalink / raw)
To: dhowells; +Cc: torvalds, akpm, netdev, penguin-kernel
In-Reply-To: <20100322135019.15704.20997.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Mon, 22 Mar 2010 13:50:19 +0000
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
> alloc_skb() can return NULL.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thanks guys.
^ permalink raw reply
* Re: linux-next: Tree for March 22 (net-sysfs.c)
From: David Miller @ 2010-03-22 17:22 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, linux-next, linux-kernel, netdev, therbert
In-Reply-To: <4BA78D3D.9090007@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 22 Mar 2010 08:31:09 -0700
> When CONFIG_SYSFS is not enabled:
>
> net/core/net-sysfs.c:742: error: implicit declaration of function 'rx_queue_remove_kobjects'
> net/core/net-sysfs.c:783: error: implicit declaration of function 'rx_queue_register_kobjects'
>
Tom, please fix this.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: David Miller @ 2010-03-22 17:17 UTC (permalink / raw)
To: vapier.adi
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <8bd0f97a1003220004q15ad498fg49914ea06c1b9a8d@mail.gmail.com>
From: Mike Frysinger <vapier.adi@gmail.com>
Date: Mon, 22 Mar 2010 03:04:48 -0400
> On Sun, Mar 21, 2010 at 23:58, David Miller wrote:
>> From: Mike Frysinger <vapier.adi@gmail.com>
>> When I say "resubmit" I've deleted your patch from my inbox
>> and marked it "changed requested" or similar in patchwork
>> so it doesn't show up in the todo list any more.
>
> i missed the relevance of your original "resubmit" because no other
> maintainer ive worked with so far has exhibited this behavior, and
> there wasnt any indication as to why a resubmission was necessary
> considering no changes were made
So when I ask you to resubmit something you just assume that
I have no reason whatsoever for doing so?
Do you still feel this way after people other than me also asked you
to do the same exact thing for me? Do you think they are making
arbitrary requests as well?
This is the fatal flaw in your logic and behavior.
^ permalink raw reply
* [iproute2] iproute2 question
From: thomas yang @ 2010-03-22 17:12 UTC (permalink / raw)
To: netdev
In-Reply-To: <f4f837ab1003221011v6657bebx3a741df5c781adf3@mail.gmail.com>
>>
>> I want to reduce the packet loss that happens while routers converge
>> after a topology change due to a failure, use precalculated backup
>> table to do rapid failure repair (repair faster than routing daemon,
>> fast reroute).
>> I do static routing on my linux routers. When some link failed,
>> I want to use backup tables to route packets. Can iproute2 do this?
>
> You could probably kludge something with multiple route tables
> and modifying a single 'ip rule'.
> Something like:
> http://www.linuxhorizon.ro/iproute2.html
>
I want to use different routing tables with different TOS (or DSCP)
e.g.
iptables -t mangle -A PREROUTING -j TOS --set-tos 0x10
...
then,
ip rule add tos 0x10 table 100
ip rule add tos 0x08 table 200
...
but there are only five TOS values 0x00,0x02,0x04,0x08,0x10. I need
more TOS values.
Does cmd 'ip rule' support DSCP ? (e.g. 'ip rule add dscp 0x11 tables 10')
^ permalink raw reply
* Re: 2.6.34-rc2: Reported regressions from 2.6.33
From: Linus Torvalds @ 2010-03-22 17:12 UTC (permalink / raw)
To: Rafael J. Wysocki, Alex Villacis Lasso
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Linux Kernel Mailing List, Linux ACPI, Andrew Morton,
Kernel Testers List, Linux PM List, Maciej Rutecki
In-Reply-To: <M9dVcHY7TxH.A.2GC.ZBopLB@chimera>
On Sun, 21 Mar 2010, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495
> Subject : Flood of SELinux denials on polkitd
> Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
> Date : 2010-03-09 16:47 (13 days old)
Fixed by commit 3836a03d978e68b0ae00d3589089343c998cd4ff ("anon_inodes:
mark the anon inode private"), I'm pretty sure.
Linus
^ permalink raw reply
* Re: 8021p to dscp remarking
From: Stephen Hemminger @ 2010-03-22 17:05 UTC (permalink / raw)
To: Smital Desai; +Cc: netdev
In-Reply-To: <70376CA23424B34D86F1C7DE6B997343017F72C982@VSHINMSMBX01.vshodc.lntinfotech.com>
----- "Smital Desai" <Smital.Desai@lntinfotech.com> wrote:
> Hello
>
> Is it possible to support 8021p -> Dscp remarking in kernel for the
> routers that
> are not supporting such kind of remarking mechanism at hardware level
> ?
>
> Any such support available in latest kernel ?
>
> Any help / suggestions will be appreciated .
>
> Thanks,
> Smital Desai
dsmark queue discipline with appropriate filters.
^ permalink raw reply
* Re: -next Mar 22: s390 build failure (drivers/s390/net/qeth_l3)
From: David Miller @ 2010-03-22 17:00 UTC (permalink / raw)
To: frank.blaschka; +Cc: sachinp, netdev, linux-s390
In-Reply-To: <20100322130025.GA8558@tuxmaker.boeblingen.de.ibm.com>
From: Blaschka <frank.blaschka@de.ibm.com>
Date: Mon, 22 Mar 2010 14:00:25 +0100
> [PATCH] qeth: l3 fix build error in ipv6 addr list handling
>
> From: Frank Blaschka <frank.blaschka@de.ibm.com>
>
> Adapt qeth l3 to:
> commit c2e21293c054817c42eb5fa9c613d2ad51954136
> (ipv6: convert addrconf list to hlist)
> converted lst_next member of inet6_ifaddr struct to a hlist.
>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Applied, thanks for fixing this Frank.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Jason Gunthorpe @ 2010-03-22 16:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-smomgflXvOZWk0Htik3J/w
In-Reply-To: <20100322132138.GC2780-YzwxZg+R7evMbnheQZGK0N5OCZ2W11yPFxja6HXR22MAvxtiuMwx3w@public.gmane.org>
On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
> Finally this bit can be removed. Currently, after the bonding driver is
> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
> that's not possible for an addr with different length than dev->addr_len
> to be present in list. Removing this check as in new mc_list there will be
> no addrlen in the record.
Maybe just make this check a WARN_ON? Can userspace create a mc_list
entry with the wrong size via netlink?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-22 16:51 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20100322163609.GZ20695@one.firstfloor.org>
On Mon, 22 Mar 2010, Andi Kleen wrote:
> Multicast reliable kernel protocols are somewhat new, I guess one
> would need to make sure to come up with a clean generic interface
> for them first.
It has been around for a long time in another OS. I wonder if I should use
the socket API realized there as a model or come up with something new
from scratch?
What I have right now is:
1. Opening a socket
A. Native PGM
fd = socket(AF_INET, SOCK_RDM, IPPROTO_PGM)
B. PGM over UDP
fd = socket(AF_INET, SOCK_RDM, IPPROTO_UDP)
C. PGM over SHM (?)
fd = socket(AF_UNIX, SOCK_RDM, 0)
2. Binding to a multicast address
A. Sender
Connect the socket to a MC address and port using connect().
Note that the port is significant since multiple streams on different
ports can be run over the same MC addr.
B. Receiver
I. Bind the socket to the MC address and port of interest.
II. Listen to the socket.
Process will wait until a PGM packet destined to the port of interest
is received.
III. Accept a connection.
Establishes a session. Data can then be received.
3. Sending and receiving
Use the usual socket read and write operations and the various flavors of waiting
for a packet via select, poll, epoll etc.
Packet sizes are determined by the number of packets in a single sendmsg() unless
overridden by the RM_SET_MESSAGE_BOUNDARY socket option.
The sender will block when the send window is full unless a non blocking write is performed.
The receiver shows the usual wait semantics. If the stream is set to unreliable then
packets may arrive in random order. If the set is set to RM_LISTEN_ONLY then packets may
just be missing.
4. Transmitter Socket Options
A. Setting the window size / rate.
struct pgm_send_window x;
x.RateKbitsPerSec = 56;
x.WindowSizeInMsecs = 60000;
x.WindowSizeinBytes = 10000000;
setsockopt(fd, SOCK_RDM, RM_RATE_WINDOW_SIZE, &x, sizeof(x));
Default is sending at 56Kbps with a buffer of 10 Megabytes and buffering for a minute.
B. FEC mode
struct pgm_fec_info x;
x.FECBlocksize = 255;
x.FECProActivePackets = 0;
x.FECGroupSize = 0;
x.fFECOnDemandParityEnabled = 1;
setsockopt(fd, SOCK_RDM, RM_FEC_MODE, &x, sizeof(x));
5. Receiver Socket Options
None?
Possible Extensions
RM_UNORDERED accept unordered packet avoiding delays when packets arrive out of sequence.
packet is still NAKed.
RM_RECEIVE_ONLY Simply ignore missed packets. Do not send any replies.
Existing socket options in the other OS (X denotes that this looks like
its screwy and should be avoided)
/* PGM socket options */
/* Transmitter */
#define RM_LATEJOIN 1 /* X Not supported on receive so why have it? */
#define RM_RATE_WINDOW_SIZE 2 /* See struct pgm_send_window */
#define RM_SEND_WINDOW_ADV_RATE 3 /* X Increase of send window in percentage of window */
#define RM_SENDER_STATISTICS 4 /* see struct pgm_sender_stats */
#define RM_SENDER_WINDOW_ADVANCE_METHOD 5 /* X seems obsolete */
#define RM_SET_MCAST_TTL 6 /* X Can be set via IP_MULTICAST_TTL */
#define RM_SET_MESSAGE_BOUNDARY 7 /* Fix the size of the messages in bytes */
#define RM_SET_SEND_IF 8 /* X use IP_MULTICAST_IF etc instead */
#define RM_USE_FEC 9
/* Receiver */
#define RM_ADD_RECEIVE_IF 100 /* X ???? IP_MULTICAST_IF instead? */
#define RM_DEL_RECEIVE_IF 101 /* X IP_MULTICAST_IF */
#define RM_HIGH_SPEED_INTRANET_OPT 102 /* X PGM should adapt automatically to high speed networks */
#define RM_RECEIVER_STATISTICS 103 /* See struct pgm_receiver_stats */
/* Socket API structures (established by M$DN) */
struct pgm_receiver_stats {
u64 NumODataPacketsReceived; /* Number of ODATA (original) sequences */
u64 NumRDataPacketsReceived; /* Number of RDATA (repair) sequences */
u64 NumDuplicateDataPackets; /* Duplicate sequences */
u64 DataBytesReceived;
u64 TotalBytesReceived;
u64 RateKBitsPerSecOverall; /* Receive rate since start of session X */
u64 RateKBitsPerSecLast; /* Receive rate for last second X*/
u64 TrailingEdgeSeqId; /* Oldest sequence in the receive window */
u64 LeadingEdgeSeqId; /* Newest sequence in the receive window */
u64 AverageSequencesInWindow; /* Average number of sequences in receive window X */
u64 MinSequencesInWindow; /* The mininum number of sequences */
u64 MaxSequencesInWindow; /* The maximum number of sequences */
u64 FirstNakSequenceNumber; /* First outstanding nack sequence number */
u64 NumPendingNaks; /* Number of sequences waiting for NCF */
u64 NumOutstandingNaks; /* Number of sequences waiting for RDATA */
u64 NumDataPacketsBuffered; /* Number of packets currently buffered */
u64 TotalSelectiveNaksSent; /* Number of NAKs sent total */
u64 TotalParityNaksSent; /* Number of parity NAKs sent */
};
struct pgm_sender_stats {
u64 DataBytesSent;
u64 TotalBytesSent;
u64 NaksReceived;
u64 NaksReceivedTooLate; /* NAKs received after receive window advanced */
u64 NumOutstandingNaks; /* Number of NAKs awaiting response */
u64 NumNaksAfterRData; /* Number of NAKs after RDATA sequences were sent which were ignored */
u64 RepairPacketsSent;
u64 BufferSpaceAvailable; /* Number of partial messages dropped */
u64 TrailingEdgeSeqId; /* Oldest sequence id in window */
u64 LeadingEdgeSeqId; /* Newest sequence id in window */
u64 RateKBitsPerSecOverall; /* Rate since start of session X */
u64 RateKBitsPerSecLast; /* Rate in last second X */
u64 TotalODataPacketsSent; /* Total data packets transmitted */
};
/* Setup of sender RateKbitsPerSec = WindowSizeBytes / WindowSizeMSecs */
struct pgm_send_window {
u64 RateKbitsPerSec; /* Allowed rate for the sender in kbits per second */
u64 WindowSizeInMSecs; /* Send window size in time */
u64 WindowSizeInBytes; /* Window size in bytes */
};
struct pgm_fec_info {
u16 FECBlockSize; /* Maximum number of packets for a group. Default and max = 255 */
u16 FECProActivePackets; /* Number of proactive packets per group. */
u8 FECGroupSize; /* Number of packets to be treated as a group. Power of two */
int fFECOnDemandParityEnabled; /* Allow sender to sent parity repair packets */
};
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Andi Kleen @ 2010-03-22 16:36 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andi Kleen, David Miller, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1003220916170.15360@router.home>
On Mon, Mar 22, 2010 at 09:20:42AM -0500, Christoph Lameter wrote:
> On Fri, 19 Mar 2010, Andi Kleen wrote:
>
> > Christoph Lameter <cl@linux-foundation.org> writes:
> > >
> > > I know about the openpgm implementation. Openpbm does this at the user
> > > level and requires linking to a library. It is essentially a communication
> > > protocol done in user space. It has privilege issues because it has to
> > > create PGM packets via a raw socket.
> >
> > That seems like a poor reason alone to put something into the kernel
> > Perhaps you rather need some way to have unpriviledged raw sockets?
>
> Not the only reason. There are also performance implications. NAKing and
> other control messages from user space are a pain and the available
> implementations add numerous threads just to control the timing of control
> messages and the expiration of data etc. Its difficult to listen to a PGM
> port from user space. You have to get all messages for the PGM protocol
> and then filter in each process.
Ok that sounds like a good reason to have a kernel protocol.
Thanks.
Multicast reliable kernel protocols are somewhat new, I guess one
would need to make sure to come up with a clean generic interface
for them first.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN module
From: Ira W. Snyder @ 2010-03-22 15:53 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sameo-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <4BA47F64.8030108-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Sat, Mar 20, 2010 at 08:55:16AM +0100, Wolfgang Grandegger wrote:
> Ira W. Snyder wrote:
> > On Fri, Mar 19, 2010 at 09:13:37PM +0100, Wolfgang Grandegger wrote:
> >> Ira W. Snyder wrote:
> >>> On Fri, Mar 19, 2010 at 04:45:09PM +0100, Wolfgang Grandegger wrote:
> >>>> Ira W. Snyder wrote:
> >>>>> On Fri, Mar 19, 2010 at 10:01:14AM +0100, Wolfgang Grandegger wrote:
> >>>>>> Hi Ira,
> >>>>>>
> >>>>>> we already discussed this patch on the SocketCAN mailing list and there
> >>>>>> are just a few minor issues and the request to add support for the new
> >>>>>> "berr-reporting" option, if feasible. See:
> >>>>>>
> >>>>>> commit 52c793f24054f5dc30d228e37e0e19cc8313f086
> >>>>>> Author: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> >>>>>> Date: Mon Feb 22 22:21:17 2010 +0000
> >>>>>>
> >>>>>> can: netlink support for bus-error reporting and counters
> >>>>>>
> >>>>>> This patch makes the bus-error reporting configurable and allows to
> >>>>>> retrieve the CAN TX and RX bus error counters via netlink interface.
> >>>>>> I have added support for the SJA1000. The TX and RX bus error counters
> >>>>>> are also copied to the data fields 6..7 of error messages when state
> >>>>>> changes are reported.
> >>>>>>
> >>>>>> Should not be a big deal.
> >>>>>>
> >>>>> I think this patch came along since my last post of the driver. I must
> >>>>> have missed it. I'll try and add support.
> >>>> No problem, it's really new. Just just need to enable BEI depending on
> >>>> CAN_CTRLMODE_BERR_REPORTING.
> >>>>
> >>> I have one final question about this.
> >>>
> >>> The documentation for the firmware isn't very specific here. I believe
> >>> that in order to get any kind of error messages, I need the bus error
> >>> feature turned on. What is the expected behavior of an SJA1000 with the
> >>> BEI (bus error interrupt) turned off? Will you still get warning
> >>> messages for ERROR_ACTIVE -> ERROR_PASSIVE state transitions?
> >> Yes. State transitions are enabled with EI and EPI.
> >>
> >
> > I cannot set the registers directly, but I think I got it right. See
> > below.
> >
> >>> I'm not sure how I would go about testing this feature, either. Ideas?
> >> Send messages without cable connected and watch the error messages with
> >> "candump any,0:0,#ffffffff". With "ip ... berr-reporting on" you should
> >> see additional bus-errors.
> >>
> >
> > Ok, I tried this. On one controller, I turned on bus-error reporting. On
> > the other, I turn off bus-error reporting. I then tried sending lots of
> > messages with the cable unplugged. Here is what happened:
> >
> > bus-error reporting on:
> > Lots of CAN_ERR_BUSERR messages are flooded in candump. There is also a
> > CAN_ERR_CRTL_TX_WARNING message, when there are too many TX errors.
>
> OK, you will now also understand why bus-error reporting is off by
> default. On low-end systems bus-error flooding may even hang the system.
>
> > bus-error reporting off:
> > There was only one message reported before the controller went into
> > ERROR-WARNING state. It was the same CAN_ERR_CRTL_TX_WARNING message as
> > above. There was no flooding of CAN_ERR_BUSERR messages.
> >
> > Does this seem right? It seems pretty good to me.
>
> Yes, I'm just missing an error-passive message. What state does "ip -d
> link show can0" report.
>
Ok, here is what I did:
$ ip link set can0 up type can bitrate 1000000
$ ip link set can1 up type can bitrate 1000000 berr-reporting on
$ ip -d -s link
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: 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 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
6: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can <BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: 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 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
Now, in seperate windows, I ran cansequence and candump. I stopped
cansequence when it could not send any more packets (due to the cable
being unplugged).
$ cansequence -v -e -p can0
$ cansequence -v -e -p can1
$ candump any,0~0,#FFFFFFFF
can0 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
This last message is repeated lots more times. That's the flooding we're
avoiding with berr-reporting off.
I see two types of messages here:
1) bus error (only on can1)
2) controller problems -- tx warning limit reached (both)
Am I missing some message? My error frame generation was mostly copied
from the sja1000 driver.
$ ip -d -s link
5: 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 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: 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
16 0 2 0 0 0
TX: bytes packets errors dropped carrier collsns
513 513 0 0 0 0
6: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can <BERR-REPORTING> state ERROR-WARNING (berr-counter tx 128 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: 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 126 0 1 0 0
RX: bytes packets errors dropped overrun mcast
1024 0 254 0 0 0
TX: bytes packets errors dropped carrier collsns
513 513 0 0 0 0
> >>> I also noticed that I can enable "self test mode" and "listen only mode"
> >>> using the same firmware command. It appears that there are netlink
> >>> messages for this as well. Should I try and support these, too? I don't
> >>> really have any use for them (yet). I assume "self test mode" is
> >>> equivalent to "loopback mode" in the netlink messages.
> >> List-only is straight forward while "self test mode" is not exactly like
> >> "loopback mode", IIRC. Feel free to send a follow-up patch when you have
> >> time for a thorough implementation and testing. It's also on my to-do
> >> list for the SJA1000.
> >>
> >
> > Ok, then I'll put this off for a while. Feel free to pester me about it
> > when there is a working implementation in the SJA1000 driver for me to
> > borrow from. :)
>
> I will let you know when I have something working.
>
Thanks,
Ira
^ permalink raw reply
* Re: [patch] stmmac: use resource_size()
From: Giuseppe CAVALLARO @ 2010-03-22 15:15 UTC (permalink / raw)
To: Dan Carpenter, netdev, Joe Perches, linux-kernel, kernel-janitors,
David S. Miller
In-Reply-To: <20100322121111.GJ21571@bicker>
Hi Dan
Thanks, the patch can also applied against the net-next driver and it's ok.
Regards,
Giuseppe
Dan Carpenter wrote:
> The size calculation is not correct. It should be end - start + 1.
> Use resource_size() to calculate it instead.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
> index a673361..92bef30 100644
> --- a/drivers/net/stmmac/stmmac_main.c
> +++ b/drivers/net/stmmac/stmmac_main.c
> @@ -1685,8 +1685,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
> }
> pr_info("done!\n");
>
> - if (!request_mem_region(res->start, (res->end - res->start),
> - pdev->name)) {
> + if (!request_mem_region(res->start, resource_size(res), pdev->name)) {
> pr_err("%s: ERROR: memory allocation failed"
> "cannot get the I/O addr 0x%x\n",
> __func__, (unsigned int)res->start);
> @@ -1694,9 +1693,9 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
> goto out;
> }
>
> - addr = ioremap(res->start, (res->end - res->start));
> + addr = ioremap(res->start, resource_size(res));
> if (!addr) {
> - pr_err("%s: ERROR: memory mapping failed \n", __func__);
> + pr_err("%s: ERROR: memory mapping failed\n", __func__);
> ret = -ENOMEM;
> goto out;
> }
> @@ -1774,7 +1773,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
> out:
> if (ret < 0) {
> platform_set_drvdata(pdev, NULL);
> - release_mem_region(res->start, (res->end - res->start));
> + release_mem_region(res->start, resource_size(res));
> if (addr != NULL)
> iounmap(addr);
> }
> @@ -1812,7 +1811,7 @@ static int stmmac_dvr_remove(struct platform_device *pdev)
>
> iounmap((void *)ndev->base_addr);
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - release_mem_region(res->start, (res->end - res->start));
> + release_mem_region(res->start, resource_size(res));
>
> free_netdev(ndev);
>
>
^ permalink raw reply
* Re: [PATCH 1/3] netlink: fix NETLINK_RECV_NO_ENOBUFS in netlink_set_err()
From: Patrick McHardy @ 2010-03-22 15:38 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netdev
In-Reply-To: <20100320.143027.116368032.davem@davemloft.net>
David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Fri, 19 Mar 2010 01:24:42 +0100
>
>
>> Patrick McHardy wrote:
>>
>>> Generally the logic seems inverted, you should return an error
>>> to conntrack if userspace wasn't notified of the error.
>>>
>> Indeed, thanks. Are you OK with this patch instead?
>>
>
> I went over all of this and now the patches #1 and #2 look
> correct to me, so I've applied them to net-2.6
>
> Patrick let me know if you think any follow-on tidy ups
> are still necessary and we can add them.
The patch looks fine to me as well, thanks Dave.
^ permalink raw reply
* Re: linux-next: Tree for March 22 (net-sysfs.c)
From: Randy Dunlap @ 2010-03-22 15:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Netdev
In-Reply-To: <20100322171937.d753bdba.sfr@canb.auug.org.au>
On 03/21/10 23:19, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20100319:
>
>
> The net tree lost its build failures.
When CONFIG_SYSFS is not enabled:
net/core/net-sysfs.c:742: error: implicit declaration of function 'rx_queue_remove_kobjects'
net/core/net-sysfs.c:783: error: implicit declaration of function 'rx_queue_register_kobjects'
--
~Randy
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-22 14:24 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: David Miller, andi, netdev, linux-kernel
In-Reply-To: <4BA3FA1D.8050204@zytor.com>
On Fri, 19 Mar 2010, H. Peter Anvin wrote:
> On 03/19/2010 02:53 PM, David Miller wrote:
> > But I also don't consider what openpbm has to do right now to
> > be all that much of a restriction. You need privileges to
> > add the protocol to the kernel, you need privileges to run
> > the userspace variant, there is no real difference.
>
> The real difference is if multiplex is needed between multiple
> unprivileged users.
It is needed. PGM ports exist and work similarly to UDP and TCP ports.
PGM as provided by openpgm and other solutions avoids native PGM and
instead uses PGM over UDP. But the routers do not support PGM over UDP in
the same way as native PGM. So the NAK suppression and other advanced
features available in Juniper and Cisco switches cannot be used.
openpbm can work with the native PGM protocol via a raw socket but then
one cannot run multiple processes communicating via different ports
effectively.
The fragmentation of packets and the assembly etc in user space is a pain.
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-22 14:20 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <87tysccjrn.fsf@basil.nowhere.org>
On Fri, 19 Mar 2010, Andi Kleen wrote:
> Christoph Lameter <cl@linux-foundation.org> writes:
> >
> > I know about the openpgm implementation. Openpbm does this at the user
> > level and requires linking to a library. It is essentially a communication
> > protocol done in user space. It has privilege issues because it has to
> > create PGM packets via a raw socket.
>
> That seems like a poor reason alone to put something into the kernel
> Perhaps you rather need some way to have unpriviledged raw sockets?
Not the only reason. There are also performance implications. NAKing and
other control messages from user space are a pain and the available
implementations add numerous threads just to control the timing of control
messages and the expiration of data etc. Its difficult to listen to a PGM
port from user space. You have to get all messages for the PGM protocol
and then filter in each process.
PGM operates on the same level as TCP and UDP.
> The classical way to do this is to start suid root, only open
> the socket and then drop privileges.
Yes those solutions exist and the experience with their limitations are
the reason to try to get PGM in the kernel.
^ permalink raw reply
* [PATCH] rxrpc: Check allocation failure.
From: David Howells @ 2010-03-22 13:50 UTC (permalink / raw)
To: torvalds, akpm; +Cc: netdev, Tetsuo Handa, David Howells
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
alloc_skb() can return NULL.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/ar-accept.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/rxrpc/ar-accept.c b/net/rxrpc/ar-accept.c
index 77228f2..2d744f2 100644
--- a/net/rxrpc/ar-accept.c
+++ b/net/rxrpc/ar-accept.c
@@ -88,6 +88,11 @@ static int rxrpc_accept_incoming_call(struct rxrpc_local *local,
/* get a notification message to send to the server app */
notification = alloc_skb(0, GFP_NOFS);
+ if (!notification) {
+ _debug("no memory");
+ ret = -ENOMEM;
+ goto error_nofree;
+ }
rxrpc_new_skb(notification);
notification->mark = RXRPC_SKB_MARK_NEW_CALL;
@@ -189,6 +194,7 @@ invalid_service:
ret = -ECONNREFUSED;
error:
rxrpc_free_skb(notification);
+error_nofree:
_leave(" = %d", ret);
return ret;
}
^ permalink raw reply related
* Re: [PATCH] Improved network performance by balancing Rx against other work
From: Nick Piggin @ 2010-03-22 13:27 UTC (permalink / raw)
To: Peter Chubb; +Cc: netdev
In-Reply-To: <87tysfu05d.wl%peterc@chubb.wattle.id.au>
On Wed, Mar 17, 2010 at 01:55:58PM +1100, Peter Chubb wrote:
> +static int e1000_intr_thread(void *data)
> +{
> + struct net_device *netdev = data;
> + struct e1000_adapter *adapter = netdev_priv(netdev);
> + const int budget = 32; // FIXME should be auto-tuneable
> + int tx_clean_complete = 0, work_done = 0;
> +
> + while(!e1000_wait_for_intr(adapter)) {
> + do {
> + work_done = 0;
> +
> + tx_clean_complete = e1000_clean_tx_irq(adapter, &adapter->tx_ring[0]);
> + adapter->clean_rx(adapter, &adapter->rx_ring[0], &work_done, budget);
> + if (!tx_clean_complete)
> + work_done = budget;
> +
> + if (work_done == budget) {
> + /*
> + * Give up the rest of the timeslice to allow
> + * userspace to make forward progress
> + */
> + sys_sched_yield();
sched_yield literally has undefined semantics if you are in SCHED_OTHER
priority (which your thread is). sched_yield use in userspace and even
kernel has caused headaches whenever the scheduler changes
significantly.
Please use anything but sched_yield. cond_resched() looks appropriate
here, it gives a simple resched point on !PREEMPT kernels. Then the
scheduler nice levels and newer resource controls should give sufficient
flexibility to fine tune CPU allocation after that.
> + }
> + } while (work_done == budget);
> +
> + /* If budget not fully consumed, wait for an interrupt */
> + adapter->last_icr = 0;
> + if (likely(adapter->itr_setting & 3))
> + e1000_set_itr(adapter);
> + if (!test_bit(__E1000_DOWN, &adapter->flags))
> + e1000_irq_enable(adapter);
> + }
> + return 0;
> +}
^ permalink raw reply
* [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Jiri Pirko @ 2010-03-22 13:21 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-smomgflXvOZWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Finally this bit can be removed. Currently, after the bonding driver is
changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
that's not possible for an addr with different length than dev->addr_len
to be present in list. Removing this check as in new mc_list there will be
no addrlen in the record.
Signed-off-by: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index d41ea27..19eba3c 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -767,11 +767,8 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
}
}
-static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
- const u8 *broadcast)
+static int ipoib_mcast_addr_is_valid(const u8 *addr, const u8 *broadcast)
{
- if (addrlen != INFINIBAND_ALEN)
- return 0;
/* reserved QPN, prefix, scope */
if (memcmp(addr, broadcast, 6))
return 0;
@@ -815,7 +812,6 @@ void ipoib_mcast_restart_task(struct work_struct *work)
union ib_gid mgid;
if (!ipoib_mcast_addr_is_valid(mclist->dmi_addr,
- mclist->dmi_addrlen,
dev->broadcast))
continue;
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: -next Mar 22: s390 build failure (drivers/s390/net/qeth_l3)
From: Blaschka @ 2010-03-22 13:00 UTC (permalink / raw)
To: Sachin Sant; +Cc: netdev, linux-s390, davem
In-Reply-To: <4BA73423.6080101@in.ibm.com>
On Mon, Mar 22, 2010 at 02:40:59PM +0530, Sachin Sant wrote:
> Todays next fails to build on a s390 box with
>
> CC [M] drivers/s390/net/qeth_l3_main.o
> drivers/s390/net/qeth_l3_main.c: In function 'qeth_l3_free_vlan_addresses6':
> drivers/s390/net/qeth_l3_main.c:1931: error: incompatible types in
> assignment
> drivers/s390/net/qeth_l3_main.c:1931: error: 'struct inet6_ifaddr' has no
> member named 'lst_next'
> make[2]: *** [drivers/s390/net/qeth_l3_main.o] Error 1
>
Hi, this patch should fix the problem
Thanks
Frank
---
[PATCH] qeth: l3 fix build error in ipv6 addr list handling
From: Frank Blaschka <frank.blaschka@de.ibm.com>
Adapt qeth l3 to:
commit c2e21293c054817c42eb5fa9c613d2ad51954136
(ipv6: convert addrconf list to hlist)
converted lst_next member of inet6_ifaddr struct to a hlist.
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_l3_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1928,7 +1928,7 @@ static void qeth_l3_free_vlan_addresses6
in6_dev = in6_dev_get(vlan_group_get_device(card->vlangrp, vid));
if (!in6_dev)
return;
- for (ifa = in6_dev->addr_list; ifa; ifa = ifa->lst_next) {
+ list_for_each_entry(ifa, &in6_dev->addr_list, if_list) {
addr = qeth_l3_get_addr_buffer(QETH_PROT_IPV6);
if (addr) {
memcpy(&addr->u.a6.addr, &ifa->addr,
^ permalink raw reply
* Re: [Patch] netconsole: do not depend on experimental
From: Neil Horman @ 2010-03-22 12:59 UTC (permalink / raw)
To: Amerigo Wang; +Cc: linux-kernel, netdev, David Miller
In-Reply-To: <20100322100305.5518.29500.sendpatchset@localhost.localdomain>
On Mon, Mar 22, 2010 at 05:59:23AM -0400, Amerigo Wang wrote:
>
> Nowadays, most distributions enable netconsole by default,
> including RHEL, Fedora, Debian, Arch, Opensuse. And
> we don't have any bug reports about it. So I think there
> is no need to mark it as experimental any more.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
> ---
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 0ba5b8e..e3d6c52 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -3252,15 +3252,14 @@ config NET_FC
> "SCSI generic support".
>
> config NETCONSOLE
> - tristate "Network console logging support (EXPERIMENTAL)"
> - depends on EXPERIMENTAL
> + tristate "Network console logging support"
> ---help---
> If you want to log kernel messages over the network, enable this.
> See <file:Documentation/networking/netconsole.txt> for details.
>
> config NETCONSOLE_DYNAMIC
> - bool "Dynamic reconfiguration of logging targets (EXPERIMENTAL)"
> - depends on NETCONSOLE && SYSFS && EXPERIMENTAL
> + bool "Dynamic reconfiguration of logging targets"
> + depends on NETCONSOLE && SYSFS
> select CONFIGFS_FS
> help
> This option enables the ability to dynamically reconfigure target
> --
Seems reasonable. Netconsole seems pretty mature.
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [Patch v2] netpoll: warn when there are spaces in parameters
From: Neil Horman @ 2010-03-22 12:30 UTC (permalink / raw)
To: Amerigo Wang; +Cc: linux-kernel, netdev, elendil, David Miller
In-Reply-To: <20100322090341.5289.10770.sendpatchset@localhost.localdomain>
On Mon, Mar 22, 2010 at 04:59:58AM -0400, Amerigo Wang wrote:
> v2: update according to Frans' comments.
>
> Currently, if we leave spaces before dst port,
> netconsole will silently accept it as 0. Warn about this.
>
> Also, when spaces appear in other places, make them
> visible in error messages.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: David Miller <davem@davemloft.net>
>
> ---
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 7aa6972..6df1863 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -614,7 +614,7 @@ void netpoll_print_options(struct netpoll *np)
> np->name, np->local_port);
> printk(KERN_INFO "%s: local IP %pI4\n",
> np->name, &np->local_ip);
> - printk(KERN_INFO "%s: interface %s\n",
> + printk(KERN_INFO "%s: interface '%s'\n",
> np->name, np->dev_name);
> printk(KERN_INFO "%s: remote port %d\n",
> np->name, np->remote_port);
> @@ -661,6 +661,9 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
> if ((delim = strchr(cur, '@')) == NULL)
> goto parse_failed;
> *delim = 0;
> + if (*cur == ' ' || *cur == '\t')
> + printk(KERN_INFO "%s: warning: whitespace"
> + "is not allowed\n", np->name);
> np->remote_port = simple_strtol(cur, NULL, 10);
> cur = delim;
> }
> @@ -708,7 +711,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
> return 0;
>
> parse_failed:
> - printk(KERN_INFO "%s: couldn't parse config at %s!\n",
> + printk(KERN_INFO "%s: couldn't parse config at '%s'!\n",
> np->name, cur);
> return -1;
> }
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ 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