* Re: [PATCH] ll_temac: Fix section mismatch from the temac_of_probe
From: David Miller @ 2011-01-03 20:07 UTC (permalink / raw)
To: grant.likely; +Cc: monstr, netdev, linux-kernel, devicetree-discuss
In-Reply-To: <20110103170332.GB2522@angua.secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Mon, 3 Jan 2011 10:03:32 -0700
> On Mon, Jan 03, 2011 at 11:32:36AM +0100, Michal Simek wrote:
>> Replace __init by __devinit.
>>
>> Warning message:
>> WARNING: vmlinux.o(.data+0xbc14): Section mismatch in reference from the variable
>> temac_of_driver to the function .init.text:temac_of_probe()
>> The variable temac_of_driver references
>> the function __init temac_of_probe()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/1] bridge: stp: ensure mac header is set
From: David Miller @ 2011-01-03 20:10 UTC (permalink / raw)
To: fw; +Cc: netdev, acme
In-Reply-To: <1294064188-17722-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 3 Jan 2011 15:16:28 +0100
> commit bf9ae5386bca8836c16e69ab8fdbe46767d7452a
> (llc: use dev_hard_header) removed the
> skb_reset_mac_header call from llc_mac_hdr_init.
>
> This seems fine itself, but br_send_bpdu() invokes ebtables LOCAL_OUT.
>
> We oops in ebt_basic_match() because it assumes eth_hdr(skb) returns
> a meaningful result.
>
> Cc: acme@ghostprotocols.net
> References: https://bugzilla.kernel.org/show_bug.cgi?id=24532
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH, second try] Typo in comments in include/linux/igmp.h
From: David Miller @ 2011-01-03 20:11 UTC (permalink / raw)
To: fx.lebail; +Cc: netdev
In-Reply-To: <542376.97776.qm@web62505.mail.re1.yahoo.com>
From: François-Xavier Le Bail <fx.lebail@yahoo.com>
Date: Mon, 3 Jan 2011 08:03:36 -0800 (PST)
> [Second try, patch invalid, sorry]
You need to provide a proper "Signed-off-by: " tag in your commit
message.
Please read Documentation/SubmittingPatches and resubmit your patch.
^ permalink raw reply
* Re: [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: David Miller @ 2011-01-03 20:13 UTC (permalink / raw)
To: shemminger; +Cc: xiaosuo, bridge, netdev
In-Reply-To: <20110103101533.3f98b311@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 3 Jan 2011 10:15:33 -0800
> On Mon, 03 Jan 2011 09:22:14 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Mon, 3 Jan 2011 18:44:59 +0800
>>
>> > On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
>> >> From: Changli Gao <xiaosuo@gmail.com>
>> >> Date: Sat, 25 Dec 2010 21:41:30 +0800
>> >>
>> >>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>> >>> we should check the length of skb after it to handle the ppoe skbs.
>> >>>
>> >>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> >>
>> >> This is really strange.
>> >>
>> >> packet_length() subtracts VLAN_HLEN from the value it returns, so the
>> >> correct fix seems to be to make this function handle the PPPOE case
>> >> too.
>> >>
>> >
>> > It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
>> > example, the MTU of ethernet is normally 1500, however the actual MTU
>> > of the 802.1Q is 1504.
>>
>> Yes, I understand this, but I don't see why packet_length() cannot
>> simply account for PPPOE's encapsulation overhead just as it does for
>> VLAN's special MTU considerations.
>
> Because PPPOE happens afterwards and is not part the calculation.
> The check should be moved until after skb has reached final form.
That works for me.
^ permalink raw reply
* Re: [PATCH] sch_red: report backlog information
From: David Miller @ 2011-01-03 20:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: hadi, jarkao2, hawk, kaber, netdev
In-Reply-To: <1294078298.2892.1111.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Jan 2011 19:11:38 +0100
> Provide child qdisc backlog (byte count) information so that "tc -s
> qdisc" can report it to user.
>
> packet count is already correctly provided.
>
> qdisc red 11: parent 1:11 limit 60Kb min 15Kb max 45Kb ecn
> Sent 3116427684 bytes 1415782 pkt (dropped 8, overlimits 7866 requeues 0)
> rate 242385Kbit 13630pps backlog 13560b 8p requeues 0
> marked 7865 early 1 pdrop 7 other 0
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Simplified 16 bit Toeplitz hash algorithm
From: Ben Hutchings @ 2011-01-03 20:15 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, therbert@google.com, netdev@vger.kernel.org
In-Reply-To: <4D2228E0.9030908@intel.com>
On Mon, 2011-01-03 at 11:52 -0800, Alexander Duyck wrote:
> On 1/3/2011 11:30 AM, Ben Hutchings wrote:
> > On Mon, 2011-01-03 at 11:02 -0800, David Miller wrote:
> >> From: Tom Herbert<therbert@google.com>
> >> Date: Mon, 3 Jan 2011 10:47:20 -0800
> >>
> >>> I'm not sure why this would be needed. What is the a advantage in
> >>> making the TX and RX queues match?
> >>
> >> That's how their hardware based RFS essentially works.
> >>
> >> Instead of watching for "I/O system calls" like we do in software, the
> >> chip watches for which TX queue a flow ends up on and matches things
> >> up on the receive side with the same numbered RX queue to match.
> >
> > ixgbe also implements IRQ affinity setting (or rather hinting) and TX
> > queue selection by CPU, the inverse of IRQ affinity setting. Together
> > with the hardware/firmware Flow Director feature, this should indeed
> > result in hardware RFS. (However, irqbalanced does not yet follow the
> > affinity hints AFAIK, so this requires some manual intervention. Maybe
> > the OOT driver is different?)
> >
> > The proposed change to make TX queue selection hash-based seems to be a
> > step backwards.
> >
> > Ben.
> >
>
> Actually this code would only be applied in the case where Flow Director
> didn't apply such as non-TCP frames. It would essentially guarantee
> that we end up with TX/RX on the same CPU for all cases instead of just
> when Flow Director matches a given flow.
The code you posted doesn't seem to implement that, though.
> The general idea is to at least keep the traffic local to one TX/RX
> queue pair so that if we cannot match the queue pair to the application,
> perhaps the application can be affinitized to match up with the queue
> pair. Otherwise we end up with traffic getting routed to one TX queue
> on one CPU, and the RX being routed to another queue on perhaps a
> different CPU and it becomes quite difficult to match up the queues and
> the applications.
Right. That certainly seems like a Good Thing, though I believe it can
be implemented generically by recording the RX queue number on the
socket:
http://article.gmane.org/gmane.linux.network/158477
> Since the approach is based on Toeplitz it can be applied to all
> hardware capable of generating a Toeplitz based hash and as a result it
> would likely also work in a much more vendor neutral kind of way than
> Flow Director currently does.
Which I appreciate, but I'm not convinced that weakening Toeplitz is a
good way to do it.
I understand that Robert Watson (FreeBSD hacker) has been doing some
research on the security and performance implications of flow hashing
algorithms, though I haven't seen any results of that yet.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] ifb: add performance flags
From: Eric Dumazet @ 2011-01-03 20:35 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, xiaosuo, pstaszewski, netdev
In-Reply-To: <20110103.114033.28807428.davem@davemloft.net>
Le lundi 03 janvier 2011 à 11:40 -0800, David Miller a écrit :
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Mon, 3 Jan 2011 20:37:03 +0100
>
> > On Sun, Jan 02, 2011 at 09:24:36PM +0100, Eric Dumazet wrote:
> >> Le mercredi 29 décembre 2010 ?? 00:07 +0100, Jarek Poplawski a écrit :
> >>
> >> > Ingress is before vlans handler so these features and the
> >> > NETIF_F_HW_VLAN_TX flag seem useful for ifb considering
> >> > dev_hard_start_xmit() checks.
> >>
> >> OK, here is v2 of the patch then, thanks everybody.
> >>
> >>
> >> [PATCH v2 net-next-2.6] ifb: add performance flags
> >>
> >> IFB can use the full set of features flags (NETIF_F_SG |
> >> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
> >> avoid unnecessary split of some packets (GRO for example)
> >>
> >> Changli suggested to also set vlan_features,
> >
> > He also suggested more GSO flags of which especially NETIF_F_TSO6
> > seems interesting (wrt GRO)?
>
> I think at least TSO6 would very much be appropriate here.
Yes, why not, I am only wondering why loopback / dummy (and others ?)
only set NETIF_F_TSO :)
Since I want to play with ECN, I might also add NETIF_F_TSO_ECN ;)
For other flags, I really doubt it can matter on ifb ?
[PATCH v3 net-next-2.6] ifb: add performance flags
IFB can use the full set of features flags (NETIF_F_SG |
NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
avoid unnecessary split of some packets (GRO for example)
Changli suggested to also set vlan_features, NETIF_F_TSO6,
NETIF_F_TSO_ECN.
Jarek suggested to add NETIF_F_HW_VLAN_TX as well.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Changli Gao <xiaosuo@gmail.com>
Cc: Jarek Poplawski <jarkao2@gmail.com>
Cc: Pawel Staszewski <pstaszewski@itcare.pl>
---
drivers/net/ifb.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 124dac4..e07d487 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -126,6 +126,10 @@ static const struct net_device_ops ifb_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
+#define IFB_FEATURES (NETIF_F_NO_CSUM | NETIF_F_SG | NETIF_F_FRAGLIST | \
+ NETIF_F_TSO_ECN | NETIF_F_TSO | NETIF_F_TSO6 | \
+ NETIF_F_HIGHDMA | NETIF_F_HW_VLAN_TX)
+
static void ifb_setup(struct net_device *dev)
{
/* Initialize the device structure. */
@@ -136,6 +140,9 @@ static void ifb_setup(struct net_device *dev)
ether_setup(dev);
dev->tx_queue_len = TX_Q_LIMIT;
+ dev->features |= IFB_FEATURES;
+ dev->vlan_features |= IFB_FEATURES;
+
dev->flags |= IFF_NOARP;
dev->flags &= ~IFF_MULTICAST;
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v2 3/3] net_sched: implement a root container qdisc sch_mclass
From: John Fastabend @ 2011-01-03 20:37 UTC (permalink / raw)
To: Jarek Poplawski
Cc: davem@davemloft.net, netdev@vger.kernel.org, hadi@cyberus.ca,
shemminger@vyatta.com, tgraf@infradead.org,
eric.dumazet@gmail.com, bhutchings@solarflare.com,
nhorman@tuxdriver.com
In-Reply-To: <20110103170244.GA1843@del.dom.local>
On 1/3/2011 9:02 AM, Jarek Poplawski wrote:
> On Sun, Jan 02, 2011 at 09:43:27PM -0800, John Fastabend wrote:
>> On 12/30/2010 3:37 PM, Jarek Poplawski wrote:
>>> John Fastabend wrote:
>>>> This implements a mclass 'multi-class' queueing discipline that by
>>>> default creates multiple mq qdisc's one for each traffic class. Each
>>>> mq qdisc then owns a range of queues per the netdev_tc_txq mappings.
>>>
>>> Is it really necessary to add one more abstraction layer for this,
>>> probably not most often used (or even asked by users), functionality?
>>> Why mclass can't simply do these few things more instead of attaching
>>> (and changing) mq?
>>>
>>
>> The statistics work nicely when the mq qdisc is used.
>
> Well, I sometimes add leaf qdiscs only to get class stats with less
> typing, too ;-)
>
>>
>> qdisc mclass 8002: root tc 4 map 0 1 2 3 0 1 2 3 1 1 1 1 1 1 1 1
>> queues:(0:1) (2:3) (4:5) (6:15)
>> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8003: parent 8002:1
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8004: parent 8002:2
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8005: parent 8002:3
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc mq 8006: parent 8002:4
>> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc sfq 8007: parent 8005:1 limit 127p quantum 1514b
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> qdisc sfq 8008: parent 8005:2 limit 127p quantum 1514b
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>>
>> The mclass gives the statistics for the interface and then statistics on the mq qdisc gives statistics for each traffic class. Also, when using the 'mq qdisc' with this abstraction other qdisc can be grafted onto the queue. For example the sch_sfq is used in the above example.
>
> IMHO, these tc offsets and counts make simply two level hierarchy
> (classes with leaf subclasses) similarly (or simpler) to other
> classful qdisc which manage it all inside one module. Of course,
> we could think of another way of code organization, but it should
> be rather done at the beginning of schedulers design. The mq qdisc
> broke the design a bit adding a fake root, but I doubt we should go
> deeper unless it's necessary. Doing mclass (or something) as a more
> complex alternative to mq should be enough. Why couldn't mclass graft
> sch_sfq the same way as mq?
>
If you also want to graft a scheduler onto a traffic class now your stuck. For now this qdisc doesn't exist, but I would like to have a software implementation of the currently offloaded DCB ETS scheduler. The 802.1Qaz spec allows different scheduling algorithms to be used on each traffic class. In the current implementation mclass could graft these scheduling schemes onto each traffic class independently.
mclass
|
-------------------------------------------------------
| | | | | | | |
mq_tbf mq_tbf mq_ets mq_ets mq mq mq_wrr greedy
| |
--------- ---------
| | | | | |
red red red red red red
Perhaps, being concerned with hypothetical qdiscs is a bit of a stretch but I would like to at least not preclude this work from being done in the future.
>>
>> Although I am not too hung up on this use case it does seem to be a good abstraction to me. Is it strictly necessary though no and looking at the class statistics of mclass could be used to get stats per traffic class.
>
> I am not too hung up on this either, especially if it's OK to others,
> especially to DaveM ;-)
>
>>
>>> ...
>>>> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
>>>> index 0af57eb..723ee52 100644
>>>> --- a/include/net/sch_generic.h
>>>> +++ b/include/net/sch_generic.h
>>>> @@ -50,6 +50,7 @@ struct Qdisc {
>>>> #define TCQ_F_INGRESS 4
>>>> #define TCQ_F_CAN_BYPASS 8
>>>> #define TCQ_F_MQROOT 16
>>>> +#define TCQ_F_MQSAFE 32
>>>
>>> If every other qdisc added a flag for qdiscs it likes...
>>>
>>
>> then we run out of bits and get unneeded complexity. I think I will drop the MQSAFE bit completely and let user space catch this. The worst that should happen is the noop qdisc is used.
>
> Maybe you're right. On the other hand, usually flags are added for
> more general purpose and the optimal/wrong configs are the matter of
> documentation.
>
So we handle this with documentation.
>>
>>>> @@ -709,7 +709,13 @@ static void attach_default_qdiscs(struct net_device *dev)
>>>> dev->qdisc = txq->qdisc_sleeping;
>>>> atomic_inc(&dev->qdisc->refcnt);
>>>> } else {
>>>> - qdisc = qdisc_create_dflt(txq, &mq_qdisc_ops, TC_H_ROOT);
>>>> + if (dev->num_tc)
>>>
>>> Actually, where this num_tc is expected to be set? I can see it inside
>>> mclass only, with unsetting on destruction, but probably I miss something.
>>
>> Either through mclass as you noted or a driver could set the num_tc. One of the RFC's I sent out has ixgbe setting the num_tc when DCB was enabled.
>
> OK, I probably missed this second possibility in the last version.
>
> ...
>>>> + /* Unwind attributes on failure */
>>>> + u8 unwnd_tc = dev->num_tc;
>>>> + u8 unwnd_map[16];
>>>
>>> [TC_MAX_QUEUE] ?
>>
>> Actually TC_BITMASK+1 is probably more accurate. This array maps the skb priority to a traffic class after the priority is masked with TC_BITMASK.
>>
>>>
>>>> + struct netdev_tc_txq unwnd_txq[16];
>>>> +
>>
>> Although unwnd_txq should be TC_MAX_QUEUE.
> ...
>>>> + /* Always use supplied priority mappings */
>>>> + for (i = 0; i < 16; i++) {
>>>
>>> i < qopt->num_tc ?
>>
>> Nope, TC_BITMASK+1 here. If we only have 4 tcs for example we still need to map all 16 priority values to a tc.
>
> OK, anyway, all these '16' should be 'upgraded'.
Yes. I'll do this in the next version.
Thanks,
John.
>
> Thanks,
> Jarek P.
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2011-01-03 20:38 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Rob Landley, Trond Myklebust, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101231130329.GA3610-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
On 12/31/2010 07:03 AM, Kirill A. Shutemov wrote:
> EXPORT_SYMBOL_GPL(get_rpc_pipefs);
>
> Something like this? Patch to replace patch #10 attached.
Looks good to me. Thanks.
acked-by: Rob Landley <rlandley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [PATCH v2 net-next-2.6] ifb: add performance flags
From: David Miller @ 2011-01-03 20:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, xiaosuo, pstaszewski, netdev
In-Reply-To: <1294086922.2711.18.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Jan 2011 21:35:22 +0100
> Le lundi 03 janvier 2011 à 11:40 -0800, David Miller a écrit :
>> I think at least TSO6 would very much be appropriate here.
>
> Yes, why not, I am only wondering why loopback / dummy (and others ?)
> only set NETIF_F_TSO :)
TSO6 probably didn't exist when the current set were added,
at least in the loopback case that's almost certainly the
reason.
> Since I want to play with ECN, I might also add NETIF_F_TSO_ECN ;)
>
> For other flags, I really doubt it can matter on ifb ?
>
> [PATCH v3 net-next-2.6] ifb: add performance flags
>
> IFB can use the full set of features flags (NETIF_F_SG |
> NETIF_F_FRAGLIST | NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA) to
> avoid unnecessary split of some packets (GRO for example)
>
> Changli suggested to also set vlan_features, NETIF_F_TSO6,
> NETIF_F_TSO_ECN.
>
> Jarek suggested to add NETIF_F_HW_VLAN_TX as well.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll apply this, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2011-01-03 20:48 UTC (permalink / raw)
To: Trond Myklebust
Cc: Kirill A. Shutemov, Rob Landley, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs, David S. Miller, netdev, linux-kernel
In-Reply-To: <1293814441.2980.4.camel@heimdal.trondhjem.org>
On 12/31/2010 10:54 AM, Trond Myklebust wrote:
>> I'm kind of surprised that the kernel cares about a specific path under
>> /var/lib. (Seems like policy in the kernel somehow.) Can't it just
>> check the current process's mount list to see if an instance of
>> rpc_pipefs is mounted in the current namespace the way lxc looks for
>> cgroups? Or are there potential performance/scalability issues with that?
>
> The kernel doesn't give a damn about the /var/lib/nfs/rpc_pipefs bit.
> That's all for the benefit of the userland utilities.
Are you saying that if you go into a container and that mount point
doesn't exist, the kernel will still be able to find and use rpc_pipefs?
Without userspace creating a specific magic path and mounting a
filesystem on it?
If so, I misread the patch...
Rob
^ permalink raw reply
* [PATCH] ksz884x: Fix section mismatch derived from pcidev_init()
From: Sedat Dilek @ 2011-01-03 21:06 UTC (permalink / raw)
To: netdev, linux-kernel, davem; +Cc: Sedat Dilek
This fixes the following warning:
WARNING: drivers/net/ksz884x.o(.data+0x18): Section mismatch in reference from the variable pci_device_driver to the function .init.text:pcidev_init()
The variable pci_device_driver references
the function __init pcidev_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Tested with linux-next (next-20101231)
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/net/ksz884x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ksz884x.c b/drivers/net/ksz884x.c
index 49ea870..540a8dc 100644
--- a/drivers/net/ksz884x.c
+++ b/drivers/net/ksz884x.c
@@ -6953,7 +6953,7 @@ static void read_other_addr(struct ksz_hw *hw)
#define PCI_VENDOR_ID_MICREL_KS 0x16c6
#endif
-static int __init pcidev_init(struct pci_dev *pdev,
+static int __devinit pcidev_init(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct net_device *dev;
--
1.7.4.rc0
^ permalink raw reply related
* Re: [PATCH] ksz884x: Fix section mismatch derived from pci_device_driver variable
From: Sedat Dilek @ 2011-01-03 21:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20110103.115248.179942629.davem@davemloft.net>
On Mon, Jan 3, 2011 at 8:52 PM, David Miller <davem@davemloft.net> wrote:
> From: Sedat Dilek <sedat.dilek@googlemail.com>
> Date: Mon, 3 Jan 2011 03:01:44 +0100
>
>> WARNING: drivers/net/ksz884x.o(.data+0x18): Section mismatch in reference from the variable pci_device_driver to the function .init.text:pcidev_init()
>> The variable pci_device_driver references
>> the function __init pcidev_init()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>>
>> This patch fixes the warning.
>>
>> Tested with linux-next (next-20101231)
>>
>> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
>
> pcidev_init() should be marked __devinit instead of __init to fix this
> bug.
>
I have sent a new fixed version.
- Sedat -
^ permalink raw reply
* [net-next-2.6] net/bridge: fix trivial sparse errors
From: Tomas Winkler @ 2011-01-03 21:08 UTC (permalink / raw)
To: davem; +Cc: netdev, Tomas Winkler
net/bridge//br_stp_if.c:148:66: warning: conversion of
net/bridge//br_stp_if.c:148:66: int to
net/bridge//br_stp_if.c:148:66: int enum umh_wait
net/bridge//netfilter/ebtables.c:1150:30: warning: Using plain integer as NULL pointer
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
net/bridge/br_stp_if.c | 2 +-
net/bridge/netfilter/ebtables.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 1d88269..79372d4 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -145,7 +145,7 @@ static void br_stp_stop(struct net_bridge *br)
char *envp[] = { NULL };
if (br->stp_enabled == BR_USER_STP) {
- r = call_usermodehelper(BR_STP_PROG, argv, envp, 1);
+ r = call_usermodehelper(BR_STP_PROG, argv, envp, UMH_WAIT_PROC);
br_info(br, "userspace STP stopped, return code %d\n", r);
/* To start timers on any ports left in blocking */
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index cbc9f39..16df053 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1147,7 +1147,7 @@ ebt_register_table(struct net *net, const struct ebt_table *input_table)
void *p;
if (input_table == NULL || (repl = input_table->table) == NULL ||
- repl->entries == 0 || repl->entries_size == 0 ||
+ repl->entries == NULL || repl->entries_size == 0 ||
repl->counters != NULL || input_table->private != NULL) {
BUGPRINT("Bad table data for ebt_register_table!!!\n");
return ERR_PTR(-EINVAL);
--
1.7.3.4
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [PATCH] smsc-ircc2: Fix section mismatch derived from smsc_ircc_pnp_probe()
From: Sedat Dilek @ 2011-01-03 21:15 UTC (permalink / raw)
To: samuel, netdev, linux-kernel, davem; +Cc: Sedat Dilek
This fixes the following warning:
drivers/net/irda/smsc-ircc2.o(.data+0x18): Section mismatch in reference from the variable smsc_ircc_pnp_driver to the function .init.text:smsc_ircc_pnp_probe()
The variable smsc_ircc_pnp_driver references
the function __init smsc_ircc_pnp_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Tested with linux-next (next-20101231)
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/net/irda/smsc-ircc2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 8c57bfb..1c1677c 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -376,7 +376,7 @@ MODULE_DEVICE_TABLE(pnp, smsc_ircc_pnp_table);
static int pnp_driver_registered;
#ifdef CONFIG_PNP
-static int __init smsc_ircc_pnp_probe(struct pnp_dev *dev,
+static int __devinit smsc_ircc_pnp_probe(struct pnp_dev *dev,
const struct pnp_device_id *dev_id)
{
unsigned int firbase, sirbase;
--
1.7.4.rc0
^ permalink raw reply related
* Re: [PATCH] smsc-ircc2: Fix section mismatch derived from smsc_ircc_pnp_driver variable
From: Sedat Dilek @ 2011-01-03 21:16 UTC (permalink / raw)
To: David Miller; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <20110103.115319.245401044.davem@davemloft.net>
On Mon, Jan 3, 2011 at 8:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Sedat Dilek <sedat.dilek@googlemail.com>
> Date: Mon, 3 Jan 2011 03:28:44 +0100
>
>>>From my build.log:
>>
>> drivers/net/irda/smsc-ircc2.o(.data+0x18): Section mismatch in reference from the variable smsc_ircc_pnp_driver to the function .init.text:smsc_ircc_pnp_probe()
>> The variable smsc_ircc_pnp_driver references
>> the function __init smsc_ircc_pnp_probe()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>>
>> This patch fixes the warning.
>>
>> Tested with linux-next (next-20101231)
>>
>> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
>
> Just like your other patch, this fix is not correct.
>
> Mark smsc_ircc_pbp_probe() as __devinit instead of __init to fix
> this bug.
>
I have sent a new fixed version.
- Sedat -
^ permalink raw reply
* [PATCH] depca: Fix section mismatch derived from depca_isa_probe()
From: Sedat Dilek @ 2011-01-03 21:22 UTC (permalink / raw)
To: netdev, linux-kernel, davem; +Cc: Sedat Dilek
This fixes the following warning:
WARNING: drivers/net/depca.o(.data+0x0): Section mismatch in reference from the variable depca_isa_driver to the function .init.text:depca_isa_probe()
The variable depca_isa_driver references
the function __init depca_isa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Tested with linux-next (next-20101231)
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/net/depca.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/depca.c b/drivers/net/depca.c
index 91b3846..1b48b68 100644
--- a/drivers/net/depca.c
+++ b/drivers/net/depca.c
@@ -1513,7 +1513,7 @@ static enum depca_type __init depca_shmem_probe (ulong *mem_start)
return adapter;
}
-static int __init depca_isa_probe (struct platform_device *device)
+static int __devinit depca_isa_probe (struct platform_device *device)
{
struct net_device *dev;
struct depca_private *lp;
--
1.7.4.rc0
^ permalink raw reply related
* Re: [PATCH] depca: Fix section mismatch derived from depca_isa_driver variable
From: Sedat Dilek @ 2011-01-03 21:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20110103.115336.70200097.davem@davemloft.net>
On Mon, Jan 3, 2011 at 8:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Sedat Dilek <sedat.dilek@googlemail.com>
> Date: Mon, 3 Jan 2011 03:33:07 +0100
>
>>>From my build.log:
>>
>> WARNING: drivers/net/depca.o(.data+0x0): Section mismatch in reference from the variable depca_isa_driver to the function .init.text:depca_isa_probe()
>> The variable depca_isa_driver references
>> the function __init depca_isa_probe()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>>
>> This patch fixes the warning.
>>
>> Tested with linux-next (next-20101231)
>>
>> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
>
> Again, mark depca_isa_probe() as __devinit to fix this bug.
>
Thanks for the pointer, I have sent a new fixed version.
- Sedat -
^ permalink raw reply
* Re: [PATCH] depca: Fix section mismatch derived from depca_isa_probe()
From: David Miller @ 2011-01-03 21:28 UTC (permalink / raw)
To: sedat.dilek; +Cc: netdev, linux-kernel, sedat.dilek
In-Reply-To: <1294089735-3031-1-git-send-email-sedat.dilek@gmail.com>
From: Sedat Dilek <sedat.dilek@googlemail.com>
Date: Mon, 3 Jan 2011 22:22:15 +0100
> This fixes the following warning:
>
> WARNING: drivers/net/depca.o(.data+0x0): Section mismatch in reference from the variable depca_isa_driver to the function .init.text:depca_isa_probe()
> The variable depca_isa_driver references
> the function __init depca_isa_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Tested with linux-next (next-20101231)
>
> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ksz884x: Fix section mismatch derived from pcidev_init()
From: David Miller @ 2011-01-03 21:27 UTC (permalink / raw)
To: sedat.dilek; +Cc: netdev, linux-kernel, sedat.dilek
In-Reply-To: <1294088818-2903-1-git-send-email-sedat.dilek@gmail.com>
From: Sedat Dilek <sedat.dilek@googlemail.com>
Date: Mon, 3 Jan 2011 22:06:58 +0100
> This fixes the following warning:
>
> WARNING: drivers/net/ksz884x.o(.data+0x18): Section mismatch in reference from the variable pci_device_driver to the function .init.text:pcidev_init()
> The variable pci_device_driver references
> the function __init pcidev_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Tested with linux-next (next-20101231)
>
> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] smsc-ircc2: Fix section mismatch derived from smsc_ircc_pnp_probe()
From: David Miller @ 2011-01-03 21:27 UTC (permalink / raw)
To: sedat.dilek; +Cc: samuel, netdev, linux-kernel, sedat.dilek
In-Reply-To: <1294089358-2968-1-git-send-email-sedat.dilek@gmail.com>
From: Sedat Dilek <sedat.dilek@googlemail.com>
Date: Mon, 3 Jan 2011 22:15:58 +0100
> This fixes the following warning:
>
> drivers/net/irda/smsc-ircc2.o(.data+0x18): Section mismatch in reference from the variable smsc_ircc_pnp_driver to the function .init.text:smsc_ircc_pnp_probe()
> The variable smsc_ircc_pnp_driver references
> the function __init smsc_ircc_pnp_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Tested with linux-next (next-20101231)
>
> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6] net/bridge: fix trivial sparse errors
From: David Miller @ 2011-01-03 21:29 UTC (permalink / raw)
To: tomas.winkler; +Cc: netdev
In-Reply-To: <1294088938-6219-1-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Mon, 3 Jan 2011 23:08:58 +0200
> net/bridge//br_stp_if.c:148:66: warning: conversion of
> net/bridge//br_stp_if.c:148:66: int to
> net/bridge//br_stp_if.c:148:66: int enum umh_wait
>
> net/bridge//netfilter/ebtables.c:1150:30: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Applied, thanks Tomas.
^ permalink raw reply
* Re: [RFC PATCH 0/3] Simplified 16 bit Toeplitz hash algorithm
From: Alexander Duyck @ 2011-01-03 21:45 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, therbert@google.com, netdev@vger.kernel.org
In-Reply-To: <1294085724.3167.202.camel@localhost>
On 1/3/2011 12:15 PM, Ben Hutchings wrote:
> On Mon, 2011-01-03 at 11:52 -0800, Alexander Duyck wrote:
>> On 1/3/2011 11:30 AM, Ben Hutchings wrote:
>>> On Mon, 2011-01-03 at 11:02 -0800, David Miller wrote:
>>>> From: Tom Herbert<therbert@google.com>
>>>> Date: Mon, 3 Jan 2011 10:47:20 -0800
>>>>
>>>>> I'm not sure why this would be needed. What is the a advantage in
>>>>> making the TX and RX queues match?
>>>>
>>>> That's how their hardware based RFS essentially works.
>>>>
>>>> Instead of watching for "I/O system calls" like we do in software, the
>>>> chip watches for which TX queue a flow ends up on and matches things
>>>> up on the receive side with the same numbered RX queue to match.
>>>
>>> ixgbe also implements IRQ affinity setting (or rather hinting) and TX
>>> queue selection by CPU, the inverse of IRQ affinity setting. Together
>>> with the hardware/firmware Flow Director feature, this should indeed
>>> result in hardware RFS. (However, irqbalanced does not yet follow the
>>> affinity hints AFAIK, so this requires some manual intervention. Maybe
>>> the OOT driver is different?)
>>>
>>> The proposed change to make TX queue selection hash-based seems to be a
>>> step backwards.
>>>
>>> Ben.
>>>
>>
>> Actually this code would only be applied in the case where Flow Director
>> didn't apply such as non-TCP frames. It would essentially guarantee
>> that we end up with TX/RX on the same CPU for all cases instead of just
>> when Flow Director matches a given flow.
>
> The code you posted doesn't seem to implement that, though.
Actually it does, it only takes effect in the case that flow director
isn't enabled. I just implemented it as a ndo_select_queue and then in
the case of the igb example I applied it directly, and in the case of
the ixgbe example I just added it to the end of the ndo_select_queue
function that it already had.
>
>> The general idea is to at least keep the traffic local to one TX/RX
>> queue pair so that if we cannot match the queue pair to the application,
>> perhaps the application can be affinitized to match up with the queue
>> pair. Otherwise we end up with traffic getting routed to one TX queue
>> on one CPU, and the RX being routed to another queue on perhaps a
>> different CPU and it becomes quite difficult to match up the queues and
>> the applications.
>
> Right. That certainly seems like a Good Thing, though I believe it can
> be implemented generically by recording the RX queue number on the
> socket:
>
> http://article.gmane.org/gmane.linux.network/158477
That was one of the reasons why I put this chunk of code out there as an
RFC as I didn't see anywhere where it really fit in. I wasn't sure if
anyone had a use for it or not, but I didn't see much point in keeping
it to myself and so I submitted as an RFC to see if anyone had any interest.
>> Since the approach is based on Toeplitz it can be applied to all
>> hardware capable of generating a Toeplitz based hash and as a result it
>> would likely also work in a much more vendor neutral kind of way than
>> Flow Director currently does.
>
> Which I appreciate, but I'm not convinced that weakening Toeplitz is a
> good way to do it.
>
> I understand that Robert Watson (FreeBSD hacker) has been doing some
> research on the security and performance implications of flow hashing
> algorithms, though I haven't seen any results of that yet.
>
> Ben.
>
I wasn't really sure about it either, but from what I can tell Toeplitz
is pretty weak in the first place, especially if using a static key, but
really hard to do efficiently in software with a full 40 byte key.
The advantages of the 16 bit key were that I could do the hash
computation with little CPU overhead and then I also was able to
generate the symmetric hash result so I didn't have to mess with source
and destination field ordering to generate the TX hash. Since most of
the hardware I am familiar with doesn't support more than 128 queues
anyway the 16 bit hash input and result generated via this approach
should be more than enough to handle the queue selection and
distribution needs of the hardware which was my only real concern.
Thanks for the input,
Alex
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2 3/3] net_sched: implement a root container qdisc sch_mclass
From: Jarek Poplawski @ 2011-01-03 22:59 UTC (permalink / raw)
To: John Fastabend
Cc: davem@davemloft.net, netdev@vger.kernel.org, hadi@cyberus.ca,
shemminger@vyatta.com, tgraf@infradead.org,
eric.dumazet@gmail.com, bhutchings@solarflare.com,
nhorman@tuxdriver.com
In-Reply-To: <4D2233A4.9050701@intel.com>
On Mon, Jan 03, 2011 at 12:37:56PM -0800, John Fastabend wrote:
> On 1/3/2011 9:02 AM, Jarek Poplawski wrote:
> > On Sun, Jan 02, 2011 at 09:43:27PM -0800, John Fastabend wrote:
> >> On 12/30/2010 3:37 PM, Jarek Poplawski wrote:
> >>> John Fastabend wrote:
> >>>> This implements a mclass 'multi-class' queueing discipline that by
> >>>> default creates multiple mq qdisc's one for each traffic class. Each
> >>>> mq qdisc then owns a range of queues per the netdev_tc_txq mappings.
> >>>
> >>> Is it really necessary to add one more abstraction layer for this,
> >>> probably not most often used (or even asked by users), functionality?
> >>> Why mclass can't simply do these few things more instead of attaching
> >>> (and changing) mq?
> >>>
> >>
> >> The statistics work nicely when the mq qdisc is used.
> >
> > Well, I sometimes add leaf qdiscs only to get class stats with less
> > typing, too ;-)
> >
> >>
> >> qdisc mclass 8002: root tc 4 map 0 1 2 3 0 1 2 3 1 1 1 1 1 1 1 1
> >> queues:(0:1) (2:3) (4:5) (6:15)
> >> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >> qdisc mq 8003: parent 8002:1
> >> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >> qdisc mq 8004: parent 8002:2
> >> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >> qdisc mq 8005: parent 8002:3
> >> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >> qdisc mq 8006: parent 8002:4
> >> Sent 140 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >> qdisc sfq 8007: parent 8005:1 limit 127p quantum 1514b
> >> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >> qdisc sfq 8008: parent 8005:2 limit 127p quantum 1514b
> >> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >> backlog 0b 0p requeues 0
> >>
> >> The mclass gives the statistics for the interface and then statistics on the mq qdisc gives statistics for each traffic class. Also, when using the 'mq qdisc' with this abstraction other qdisc can be grafted onto the queue. For example the sch_sfq is used in the above example.
> >
> > IMHO, these tc offsets and counts make simply two level hierarchy
> > (classes with leaf subclasses) similarly (or simpler) to other
> > classful qdisc which manage it all inside one module. Of course,
> > we could think of another way of code organization, but it should
> > be rather done at the beginning of schedulers design. The mq qdisc
> > broke the design a bit adding a fake root, but I doubt we should go
> > deeper unless it's necessary. Doing mclass (or something) as a more
> > complex alternative to mq should be enough. Why couldn't mclass graft
> > sch_sfq the same way as mq?
> >
>
> If you also want to graft a scheduler onto a traffic class now your stuck. For now this qdisc doesn't exist, but I would like to have a software implementation of the currently offloaded DCB ETS scheduler. The 802.1Qaz spec allows different scheduling algorithms to be used on each traffic class. In the current implementation mclass could graft these scheduling schemes onto each traffic class independently.
>
> mclass
> |
> -------------------------------------------------------
> | | | | | | | |
> mq_tbf mq_tbf mq_ets mq_ets mq mq mq_wrr greedy
> | |
> --------- ---------
> | | | | | |
> red red red red red red
>
> Perhaps, being concerned with hypothetical qdiscs is a bit of a stretch but I would like to at least not preclude this work from being done in the future.
Probably, despite this very nice figure and description, I still miss
something and can't see the problem. If you graft a qdisc/scheduler
to a traffic class you can change the way/range of grafting depending
on additional parameters or even by checking some properties of the
grafted qdisc. My main concern is adding complexity to the qdisc tree
structure (instead of hiding it at the class level) for something,
IMHO, hardly ever popular (like both mq and DCB).
Thanks,
Jarek P.
^ permalink raw reply
* Re: [net-next-2.6 01/08] r8169: remove the firmware of RTL8111D.
From: Ben Hutchings @ 2011-01-03 23:09 UTC (permalink / raw)
To: Francois Romieu; +Cc: davem, netdev, Hayes Wang, David Woodhouse
In-Reply-To: <20110102233552.GB5780@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On Mon, 2011-01-03 at 00:35 +0100, Francois Romieu wrote:
> The binary file of the firmware is moved to linux-firmware repository.
> The firmwares are rtl_nic/rtl8168d-1.fw and rtl_nic/rtl8168d-2.fw.
> The driver goes along if the firmware couldn't be found. However, it
> is suggested to be done with the suitable firmware.
[...]
You should also add 'select FW_LOADER' to the Kconfig section for R8169.
Ben.
--
Ben Hutchings, Debian Developer and kernel team member
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ 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