* Re: [stable] [BUG] 2.6.32.21 bnx2_napi->hw_tx_cons_ptr NULL pointer dereference
From: Greg KH @ 2010-09-23 18:40 UTC (permalink / raw)
To: David Miller; +Cc: mchan, netdev, linux-kernel, shawn.bohrer, stable
In-Reply-To: <20100908.215809.232892441.davem@davemloft.net>
On Wed, Sep 08, 2010 at 09:58:09PM -0700, David Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Wed, 8 Sep 2010 21:55:29 -0700
>
> > Shawn Bohrer wrote:
> >
> >> Is there any reason these can't/shouldn't be applied to the 2.6.32.y
> >> stable series? It looks like they apply cleanly.
> >>
> >
> > No reason. I just didn't know how far back to apply these patches.
> > The crash was triggered by changes in netpoll some time ago and
> > the problem has been present for some time.
>
> Michael, please submit these to -stable then, thanks!
Now queued up.
thanks,
greg k-h
^ permalink raw reply
* Re: [stable] [Bugme-new] [Bug 18592] New: Remote/local Denial of Service vulnerability in SCTP packet/chunk handling
From: David Miller @ 2010-09-23 19:21 UTC (permalink / raw)
To: greg
Cc: dreibh, akpm, vladislav.yasevich, netdev, bugzilla-daemon,
martin.becke, linux-sctp, stable, sri
In-Reply-To: <20100923180515.GG23040@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Thu, 23 Sep 2010 11:05:15 -0700
> On Sat, Sep 18, 2010 at 04:11:03PM +0200, Thomas Dreibholz wrote:
>> Vlad's patch solves the problem. I hope this patch can go into the mailine
>> kernel soon, in order to get distribution kernels fixed as soon as possible. It
>> is relatively easy to trigger the denial of service problem, making all
>> systems providing SCTP-based services vulnerable to a remote DoS attack.
>>
>> I have also been able to reproduce the problem with kernel 2.6.32, i.e. at
>> least all kernels from 2.6.32 to 2.6.36 are affected.
>
> Is this in Linus's tree now? If so, does anyone have the git commit id?
Should be: 4bdab43323b459900578b200a4b8cf9713ac8fab
^ permalink raw reply
* Re: [stable] [Bugme-new] [Bug 18592] New: Remote/local Denial of Service vulnerability in SCTP packet/chunk handling
From: Greg KH @ 2010-09-23 19:37 UTC (permalink / raw)
To: David Miller
Cc: dreibh, akpm, vladislav.yasevich, netdev, bugzilla-daemon,
martin.becke, linux-sctp, stable, sri
In-Reply-To: <20100923.122155.108788529.davem@davemloft.net>
On Thu, Sep 23, 2010 at 12:21:55PM -0700, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Thu, 23 Sep 2010 11:05:15 -0700
>
> > On Sat, Sep 18, 2010 at 04:11:03PM +0200, Thomas Dreibholz wrote:
> >> Vlad's patch solves the problem. I hope this patch can go into the mailine
> >> kernel soon, in order to get distribution kernels fixed as soon as possible. It
> >> is relatively easy to trigger the denial of service problem, making all
> >> systems providing SCTP-based services vulnerable to a remote DoS attack.
> >>
> >> I have also been able to reproduce the problem with kernel 2.6.32, i.e. at
> >> least all kernels from 2.6.32 to 2.6.36 are affected.
> >
> > Is this in Linus's tree now? If so, does anyone have the git commit id?
>
> Should be: 4bdab43323b459900578b200a4b8cf9713ac8fab
Wonderful, now queued up.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: john stultz @ 2010-09-23 19:38 UTC (permalink / raw)
To: Richard Cochran
Cc: Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra, linux-api,
devicetree-discuss, linux-kernel, Thomas Gleixner, netdev,
Christoph Lameter, linuxppc-dev, David Miller, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <cover.1285261533.git.richard.cochran@omicron.at>
On Thu, 2010-09-23 at 19:30 +0200, Richard Cochran wrote:
> Here is the sixth version of my patch set adding PTP hardware clock
> support to the Linux kernel. The main difference to v5 is that the
> character device interface has been replaced with one based on the
> posix clock system calls.
>
> The first three patches add necessary background support in the posix
> clock code. The last five add the new PTP hardware clock features.
> Previously, I had tried to present the posix clock changes all by
> themselves, but commentators asked to see the whole context.
Richard,
Its great to see this work continue and the patch set is shaping up
nicely! There's still a few details to work out, but I think the
remaining issues are relatively small.
> 3.2.3 Dynamic POSIX Clock IDs
> ------------------------------
>
> The reaction on the list to having a static id like CLOCK_PTP was
> mostly negative. However, the idea of generating a clock id
> dynamically seems to have gained acceptance. The general idea is
> to advertise the available clock ids to user space via sysfs. This
> patch set implements two different ways:
>
> /sys/class/timesource/<name>/id
> /sys/class/ptp/ptp_clock_X/id
>
> Note: I am not too sure that this is exactly what people imagined,
> but it is my best understanding so far. I gleaned two
> different ideas about where to offer the clock id. In order
> to keep just one way, I will be happy to remove the less
> popular one.
So yea, I'm not a fan of the "timesource" sysfs interface. One, I think
the name is poor (posix_clocks or something a little more specific would
be an improvement), and second, I don't like the dictionary interface,
where one looks up the clock by name.
Instead, I think having the id hanging off the class driver is much
better, as it allows mapping the actual hardware to the id more clearly.
So I'd drop the "timesource" listing. And maybe change "id" to
"clock_id" so its a little more clear what the id is for.
> 3.3 Synchronizing the Linux System Time
> ========================================
>
> One could offer a PHC as a combined clock source and clock event
> device. The advantage of this approach would be that it obviates
> the need for synchronization when the PHC is selected as the system
> timer. However, some PHCs, namely the PHY based clocks, cannot be
> used in this way.
Again, I'd scratch this.
What I think you might want to mention is that an application like NTP
could use the PTP clockid much like NTP currently can be configured to
use the RTC to steer the system time.
Possibly the PTPd could just do this, reducing the number of deamons and
avoiding mixing NTP up in what is really a different sync algorithm.
> Instead, the patch set provides a way to offer a Pulse Per Second
> (PPS) event from the PHC to the Linux PPS subsystem. A user space
> application can read the PPS events and tune the system clock, just
> like when using other external time sources like radio clocks or
> GPS.
Forgive me for a bit of a tangent here:
So while I think this PPS method is a neat idea, I'm a little curious
how much of a difference the PPS method for syncing the clock would be
over just a simple reading of the two clocks and correcting the offset.
It seems much of it depends on the read latency of the PTP hardware vs
the interrupt latency. Also the PTP clock granularity would effect the
read accuracy (like on the RTC, you don't really know how close to the
second boundary you are).
Have you done any such measurements between the two methods? I just
wonder if it would actually be something noticeable, and if its not, how
much lighter this patch-set would be without the PPS connection.
Again, this isn't super critical, just trying to make sure we don't end
up adding a bunch of code that doesn't end up being used. Also PPS
interrupts are awfully frequent, so systems concerned with power-saving
and deep idles probably would like something that could be done at a
more coarse interval.
> 3.5 User timers
> ================
>
> Using the POSIX clock API gived user space the possibility to
> create and use timers with timer_create and timer_settime. In the
> current patch set the kernel functionality is not implemented,
> since there are some issues to consider first. I see two ways to do
> about this.
>
> 1. Implement the functionality anew. This approach might end up
> duplicating similar code that already exists. Also, looking at
> the hrtimer code, getting user timers right seems to have a
> number of gotchas and thorny issues.
>
> 2. Reuse the hrtimer code. Since the hrtimer code uses a clock
> event device under the hood, it might be possible (in theory) to
> offer capable PHCs as clock event devices. However, the current
> hrtimers are hard-coded to the event device via a per-cpu
> global. Perhaps one could associate an event device with a
> hrtimer via the timer itself.
>
> At this point I am not optimistic about either approach, and I
> would vote for postponing the timer issue indefinitely. The
> implementation effort would be high, but the utility low.
So I'm working on this! I've pulled out the basic rbtree based timer
list manipulation out of the hrtimer code and into its own lib code.
I'll send those patches out for RFC shortly.
> If the Linux system time is synchronized to the PHC via the PPS
> method, then using standard hrtimers would be good enough for most
> purposes. Consider the time scales involved. The PHC can be
> synchronized to within 100 nanoseconds of an external time source,
> while timer wakeup latency (even with rt kernels) is tens of
> microseconds.
Hmm. I think this point touches on my earlier tangent.
> 4 Drivers
> ~~~~~~~~~~
>
> 4.1 Supported Hardware Clocks
> ==============================
>
> + Standard Linux system timer
> This driver exports the standard Linux timer as a PTP clock.
> Although this duplicates CLOCK_REALTIME, the code serves as a
> simple example for driver development and lets people who without
> special hardware try the new API.
Still not a fan of this one, figure the app should handle the special
case where there are no PTP clocks and just use CLOCK_REALTIME rather
then funneling CLOCK_REALTIME through the PTP interface.
thanks
-john
^ permalink raw reply
* Re: [PATCH 1/8] posix clocks: introduce a syscall for clock tuning.
From: john stultz @ 2010-09-23 19:48 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <b94ef1cd9c04ef3ad5964408bd0af7251add78de.1285261534.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
>
> The new syscall, clock_adjtime, takes two parameters, the clock ID,
> and a pointer to a struct timex. The semantics of the timex struct
> have been expanded by one additional mode flag, which allows an
> absolute offset correction. When specificied, the clock offset is
> immediately corrected by adding the given time value to the current
> time value.
So I'd still split this patch up a little bit more.
1) Patch that implements the ADJ_SETOFFSET (*and its implementation*)
in do_adjtimex.
2) Patch that adds the new syscall and clock_id multiplexing.
3) Patches that wire it up to the rest of the architectures (there's
still a bunch missing here).
And one little nit in the code:
> diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
> index 9ca4973..446b566 100644
> --- a/kernel/posix-timers.c
> +++ b/kernel/posix-timers.c
> @@ -197,6 +197,14 @@ static int common_timer_create(struct k_itimer *new_timer)
> return 0;
> }
>
> +static inline int common_clock_adj(const clockid_t which_clock, struct timex *t)
> +{
> + if (CLOCK_REALTIME == which_clock)
> + return do_adjtimex(t);
> + else
> + return -EOPNOTSUPP;
> +}
Would it make sense to point to the do_adjtimex() in the k_clock
definition for CLOCK_REALTIME rather then conditionalizing it here?
thanks
-john
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Przemo Firszt @ 2010-09-23 20:16 UTC (permalink / raw)
To: Ping Cheng
Cc: Ville Tervo, ext Alan Ott, Jiri Kosina, Stefan Achatz,
Antonio Ospite, Alexey Dobriyan, Tejun Heo, Alan Stern,
Greg Kroah-Hartman, Marcel Holtmann, Stephane Chatty,
Michael Poole, David S. Miller, Bastien Nocera, Eric Dumazet,
linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <AANLkTinJXYbZh_MvG81iJMu84LKBOKL3s-Gbfe77Vq7q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dnia 2010-09-23, czw o godzinie 10:07 -0700, Ping Cheng pisze:
> On Thu, Sep 23, 2010 at 9:25 AM, Ville Tervo <ville.tervo-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> wrote:
> > Hi Alan,
> >
> > On Mon, Aug 16, 2010 at 10:20:57PM +0200, ext Alan Ott wrote:
> >> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
> >
> > I gave a try to to this patch using your test tool [1] and very old BT
> > keyboard. I don't have anything else ATM to test with. Is there some BT hid
> > devices which support setting and getting features?
>
> As far as I know Wacom BT devices (Graphire and Intuos4) need to get
> and set features.
>
> Przemo,
>
> Do you have time to test the patchset with your Graphire BT and
> provide your result here?
Hi Ping,
Speed switching works as expected.
Tested on HP NC4200 with internal and external bluetooth modules:
Linux pldmachine 2.6.35-07788-g320b2b8-dirty #15 Thu Sep 23 19:55:03 IST
2010 i686 Intel(R)_Pentium(R)_M_processor_1.86GHz PLD Linux
ID 03f0:011d Hewlett-Packard Integrated Bluetooth Module
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
and Wacom Pen Tablet CTE-630BT
Tested-by: Przemo Firszt <przemo-q9SP4D9nreWHXe+LvDLADg@public.gmane.org>
--
Regards,
Przemo Firszt <przemo-q9SP4D9nreWHXe+LvDLADg@public.gmane.org>
^ permalink raw reply
* [PATCH net-next-2.6 0/2] net, sfc: Fix number of RX queues
From: Ben Hutchings @ 2010-09-23 20:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Tom Herbert
This distinguishes the maximum and actual numbers of RX queues, adds a
function to set the actual number, and changes sfc to use it. Other
multiqueue drivers should presumably be updated similarly.
Ben.
Ben Hutchings (2):
net: Allow changing number of RX queues after device allocation
sfc: Use proper functions to set core RX and TX queue counts
drivers/net/sfc/efx.c | 3 ++-
include/linux/netdevice.h | 14 ++++++++++++++
net/core/dev.c | 43 +++++++++++++++++++++++++++++++++++++++----
net/core/net-sysfs.c | 34 +++++++++++++++++++---------------
net/core/net-sysfs.h | 4 ++++
5 files changed, 78 insertions(+), 20 deletions(-)
--
1.7.2.1
--
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
* [PATCH net-next-2.6 1/2] net: Allow changing number of RX queues after device allocation
From: Ben Hutchings @ 2010-09-23 20:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Tom Herbert
In-Reply-To: <1285273118.7794.23.camel@achroite.uk.solarflarecom.com>
For RPS, we create a kobject for each RX queue based on the number of
queues passed to alloc_netdev_mq(). However, drivers generally do not
determine the numbers of hardware queues to use until much later, so
this usually represents the maximum number the driver may use and not
the actual number in use.
For TX queues, drivers can update the actual number using
netif_set_real_num_tx_queues(). Add a corresponding function for RX
queues, netif_set_real_num_rx_queues().
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/netdevice.h | 14 ++++++++++++++
net/core/dev.c | 43 +++++++++++++++++++++++++++++++++++++++----
net/core/net-sysfs.c | 34 +++++++++++++++++++---------------
net/core/net-sysfs.h | 4 ++++
4 files changed, 76 insertions(+), 19 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index f7f1302..c2b3880 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -978,6 +978,9 @@ struct net_device {
/* Number of RX queues allocated at alloc_netdev_mq() time */
unsigned int num_rx_queues;
+
+ /* Number of RX queues currently active in device */
+ unsigned int real_num_rx_queues;
#endif
rx_handler_func_t *rx_handler;
@@ -1682,6 +1685,17 @@ static inline int netif_is_multiqueue(const struct net_device *dev)
extern void netif_set_real_num_tx_queues(struct net_device *dev,
unsigned int txq);
+#ifdef CONFIG_RPS
+extern int netif_set_real_num_rx_queues(struct net_device *dev,
+ unsigned int rxq);
+#else
+static inline int netif_set_real_num_rx_queues(struct net_device *dev,
+ unsigned int rxq)
+{
+ return 0;
+}
+#endif
+
/* Use this variant when it is known for sure that it
* is executing from hardware interrupt context or with hardware interrupts
* disabled.
diff --git a/net/core/dev.c b/net/core/dev.c
index 2c7934f..1287ce1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1567,6 +1567,38 @@ void netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
}
EXPORT_SYMBOL(netif_set_real_num_tx_queues);
+#ifdef CONFIG_RPS
+/**
+ * netif_set_real_num_rx_queues - set actual number of RX queues used
+ * @dev: Network device
+ * @rxq: Actual number of RX queues. Must not be greater than the
+ * queue count specified at device allocation time.
+ *
+ * This must be called either with the rtnl_lock held or before registration
+ * of the net device. Returns 0 on success, or a negative error code.
+ * If called before registration, it always succeeds.
+ */
+int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq)
+{
+ int rc;
+
+ if (rxq > dev->num_rx_queues)
+ return -EINVAL;
+
+ if (dev->reg_state == NETREG_REGISTERED) {
+ ASSERT_RTNL();
+ rc = net_rx_queue_update_kobjects(dev, dev->real_num_rx_queues,
+ rxq);
+ if (rc)
+ return rc;
+ }
+
+ dev->real_num_rx_queues = rxq;
+ return 0;
+}
+EXPORT_SYMBOL(netif_set_real_num_rx_queues);
+#endif
+
static inline void __netif_reschedule(struct Qdisc *q)
{
struct softnet_data *sd;
@@ -2352,10 +2384,11 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
if (skb_rx_queue_recorded(skb)) {
u16 index = skb_get_rx_queue(skb);
- if (unlikely(index >= dev->num_rx_queues)) {
- WARN_ONCE(dev->num_rx_queues > 1, "%s received packet "
- "on queue %u, but number of RX queues is %u\n",
- dev->name, index, dev->num_rx_queues);
+ if (unlikely(index >= dev->real_num_rx_queues)) {
+ WARN_ONCE(dev->real_num_rx_queues > 1,
+ "%s received packet on queue %u, but number "
+ "of RX queues is %u\n",
+ dev->name, index, dev->real_num_rx_queues);
goto done;
}
rxqueue = dev->_rx + index;
@@ -5017,6 +5050,7 @@ int register_netdevice(struct net_device *dev)
dev->_rx->first = dev->_rx;
atomic_set(&dev->_rx->count, 1);
dev->num_rx_queues = 1;
+ dev->real_num_rx_queues = 1;
}
#endif
/* Init, if this function is available */
@@ -5479,6 +5513,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
#ifdef CONFIG_RPS
dev->_rx = rx;
dev->num_rx_queues = queue_count;
+ dev->real_num_rx_queues = queue_count;
#endif
dev->gso_max_size = GSO_MAX_SIZE;
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 76485a3..4791cfc 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -742,34 +742,38 @@ static int rx_queue_add_kobject(struct net_device *net, int index)
return error;
}
-static int rx_queue_register_kobjects(struct net_device *net)
+int
+net_rx_queue_update_kobjects(struct net_device *net, int old_num, int new_num)
{
int i;
int error = 0;
-
- net->queues_kset = kset_create_and_add("queues",
- NULL, &net->dev.kobj);
- if (!net->queues_kset)
- return -ENOMEM;
- for (i = 0; i < net->num_rx_queues; i++) {
+
+ for (i = old_num; i < new_num; i++) {
error = rx_queue_add_kobject(net, i);
- if (error)
+ if (error) {
+ new_num = old_num;
break;
+ }
}
- if (error)
- while (--i >= 0)
- kobject_put(&net->_rx[i].kobj);
+ while (--i >= new_num)
+ kobject_put(&net->_rx[i].kobj);
return error;
}
-static void rx_queue_remove_kobjects(struct net_device *net)
+static int rx_queue_register_kobjects(struct net_device *net)
{
- int i;
+ net->queues_kset = kset_create_and_add("queues",
+ NULL, &net->dev.kobj);
+ if (!net->queues_kset)
+ return -ENOMEM;
+ return net_rx_queue_update_kobjects(net, 0, net->real_num_rx_queues);
+}
- for (i = 0; i < net->num_rx_queues; i++)
- kobject_put(&net->_rx[i].kobj);
+static void rx_queue_remove_kobjects(struct net_device *net)
+{
+ net_rx_queue_update_kobjects(net, net->real_num_rx_queues, 0);
kset_unregister(net->queues_kset);
}
#endif /* CONFIG_RPS */
diff --git a/net/core/net-sysfs.h b/net/core/net-sysfs.h
index 805555e..778e157 100644
--- a/net/core/net-sysfs.h
+++ b/net/core/net-sysfs.h
@@ -4,4 +4,8 @@
int netdev_kobject_init(void);
int netdev_register_kobject(struct net_device *);
void netdev_unregister_kobject(struct net_device *);
+#ifdef CONFIG_RPS
+int net_rx_queue_update_kobjects(struct net_device *, int old_num, int new_num);
+#endif
+
#endif
--
1.7.2.1
--
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 related
* [PATCH net-next-2.6 2/2] sfc: Use proper functions to set core RX and TX queue counts
From: Ben Hutchings @ 2010-09-23 20:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1285273118.7794.23.camel@achroite.uk.solarflarecom.com>
Call netif_real_num_tx_queues() instead of setting
net_device::real_num_tx_queues directly.
Also call the new netif_real_num_rx_queues() function to set the
core RX queue count correctly for RPS.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index 5be71f4..fa6e020 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1315,7 +1315,8 @@ static int efx_probe_nic(struct efx_nic *efx)
efx->rx_indir_table[i] = i % efx->n_rx_channels;
efx_set_channels(efx);
- efx->net_dev->real_num_tx_queues = efx->n_tx_channels;
+ netif_set_real_num_tx_queues(efx->net_dev, efx->n_tx_channels);
+ netif_set_real_num_rx_queues(efx->net_dev, efx->n_rx_channels);
/* Initialise the interrupt moderation settings */
efx_init_irq_moderation(efx, tx_irq_mod_usec, rx_irq_mod_usec, true);
--
1.7.2.1
--
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 related
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: john stultz @ 2010-09-23 20:28 UTC (permalink / raw)
To: Christoph Lameter
Cc: Richard Cochran, linux-kernel, devicetree-discuss, linux-api,
linux-arm-kernel, linuxppc-dev, netdev, Arnd Bergmann,
David Miller, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <alpine.DEB.2.00.1009231402420.2962@router.home>
On Thu, 2010-09-23 at 14:15 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, john stultz wrote:
>
> > This was my initial gut reaction as well, but in the end, I agree with
> > Richard that in the case of one or multiple PTP hardware clocks, we
> > really can't abstract over the different time domains.
>
> My (arguably still superficial) review of the source does not show
> anything that would make me reach that conclusion.
>
> > I really don't think the PTP clock can be used as a clocksource sanely.
> >
> > First, the hardware access is much to slow for system timekeeping.
>
> The HPET or pit timesource are also quite slow these days. You only need
> access periodically to essentially tune the TSC ratio.
If we're using the TSC, then we're not using the PTP clock as you
suggest. Further the HPET and PIT aren't used to steer the system time
when we are using the TSC as a clocksource. Its only used to calibrate
the initial constant freq used by the timekeeping code (and if its
non-constant, we throw it out).
> > Second, there is the problem that the system time is a software clock,
> > and adjustments made (like freq) are made in the layer that interprets
> > the underlying hardware cycle counter. Adjustments made in PTP (in order
> > to sync the network timestamps) are made at the hardware level.
>
> From what I can see the PTP clocks are periodic hardware cycle counters
> like any other clock that we currently support. If its configurable enough
> then setup a hardware cycle counter that mimics nanoseconds since the
> epoch as closely as possible and use that to sync the TSC rate to. Makes
> it very easy.
I guess I'm confused by what you're suggesting.
If we're using the TSC, then that's the clocksource timekeeping uses.
The original issue seemed to be around the suggestion of using the PTP
clock as a clocksource, which I don't think is really feasible.
Again, that's because
1) The PTP access latency is slow (so is the PIT, true enough, but no
one should be using the PIT as a clocksource unless they really have no
better hardware - its really only useful for 486s and old freq scaling
laptops that have no other stable clocksource).
2) The way PTP clocks are steered to sync with network time causes their
hardware freq to actually change. Since these adjustments are done on
the hardware clock level, and not on the system time level, the
adjustments to sync the system time/freq would then be made incorrect by
PTP hardware adjustments.
3) Further, the PTP hardware counter can be simply set to a new offset
to put it in line with the network time. This could cause trouble with
timekeeping much like unsynced TSCs do.
Now, what you seem to be suggesting is to use the TSC (or whatever
clocksource the system time is using) but to steer the system time using
the PTP clock. This is actually what is being proposed, however, the
steering is done in userland. This is due to the fact that there are two
components to the steering, 1) adjusting the PTP clock hardware to
network time and 2) adjusting the system time to the PTP hardware. By
exposing the PTP clock to userland via the posix clocks interface, we
allow this to easily be done.
> > This would cause a disconnect between the hardware freq understood by
> > the system time management code and the actual hardware freq.
>
> We can switch underlying clocks for system time already. We can adapt to a
> different hw frequency.
Actually no. The timekeeping code requires a fixed freq counter. Dealing
with hardware freq changes is difficult, because error is introduced by
the latency between when the freq changes and when the timekeeping code
is notified of it. So the system treats the hardware counters as fixed
freq. Now, hardware does vary freq ever so slightly as thermal
conditions change, but this is addressed in userland and corrected via
adjtimex.
> But then I do not know why adjust the freq? I
> thought the point was that the periodic clock was network synchronized and
> can be used as "the" master clock for multiple machines?
Not parsing that. What do you mean by periodic clock?
> > Richard, I'd actually strike this paragraph from the rational, as I feel
> > it has the tendency to confuse as it suggests having the PHC as a
> > clocksource is feasible when really it isn't. Or alternatively, maybe
> > express more clearly why its not feasible, so it doesn't just seem like
> > a minor design choice.
>
> Sorry but I still feel that this is pretty much a misguided approach that
> creates unnecessary layers in the kernel.
Unnecessary layers? Where? This approach has less in-kernel layers, as
it exposes the PTP clock to userland, instead of trying to layer things
on top of it and stretching the system time abstraction to cover it.
> The trivial easy approach was
> not done (copy a driver from drivers/clocksource, modify so that it
> programs access to a centralized periodic ptp signal and uses it for
> system sync).
I disagree.
I've argued through the approach trying to keep it all internal to the
kernel, but to do so would be anything but trivial. Further, there's the
case of master-clocks, where the PTP hardware must be synced to system
time, instead of the other way around. And then there's the case of
boundary-clocks, which may have multiple PTP hardware clocks that have
to be synced.
I think exposing this through the posix clock interface is really the
best approach. Its not a static clockid, so its not something most apps
will ever have to deal with, but it allows the few apps that really need
to have access to the PTP clock hardware can do so in a clean way.
And credits to Richard for having to slowly explain this to me (and
others) many times over, before I got it.
thanks
-john
^ permalink raw reply
* Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Christoph Lameter @ 2010-09-23 20:32 UTC (permalink / raw)
To: Alan Cox
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <20100923214359.3f287b11-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Thu, 23 Sep 2010, Alan Cox wrote:
> > Please do not introduce useless additional layers for clock sync. Load
> > these ptp clocks like the other regular clock modules and make them sync
> > system time like any other clock.
>
> I don't think you understand PTP. PTP has masters, a system can need to
> be honouring multiple conflicting masters at once.
The upshot of it all has to be some synchronized notion of time regardless
of how many other things are going on under the hood. And the spec here
suggests a hardware able to generate periodic accurate events that can be
used to sync system time.
> > Really guys: I want a PTP solution! Now! And not some idiotic additional
> > kernel layers that just pass bits around because its so much fun and
> > screws up clock accurary in due to the latency noise introduced while
> > having so much fun with the bits.
>
> There are some interesting complications in putting a PTP sync
> interface in kernel.
If the PTP logic internally has to juggle multiple clocks then that is a
complication for the driver ok. In any case the driver ultimately has to
provide *one* source of time for the system to sync to.
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-23 20:36 UTC (permalink / raw)
To: Richard Cochran
Cc: John Stultz, Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra,
linux-api, devicetree-discuss, linux-kernel, Thomas Gleixner,
netdev, Christoph Lameter, linuxppc-dev, David Miller,
linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <cover.1285261533.git.richard.cochran@omicron.at>
> So as far as the POSIX standard is concerned, offering a clock id
> to represent the PHC would be acceptable.
But completely useless as you may have more than one entirely different
time managed by PTP and in which you are not master but must work with
the timebases provided.
> /sys/class/timesource/<name>/id
> /sys/class/ptp/ptp_clock_X/id
>
> Note: I am not too sure that this is exactly what people imagined,
> but it is my best understanding so far. I gleaned two
> different ideas about where to offer the clock id. In order
> to keep just one way, I will be happy to remove the less
> popular one.
I see no fix proposed for the race condition I pointed out. This doesn't
work.
> If the Linux system time is synchronized to the PHC via the PPS
To which PHC we can have several
> + Intel IXP465
> - Auxiliary Slave/Master Mode Snapshot (optional interrupt)
> - Target Time (optional interrupt)
And about 40 already supported by char driver interface clocks and rtcs
in the kernel...
I'd say the inability to have multiple clocks and the race condition
because of the clockid stuff leaves the proposal dead in the water.
It also ignores the existing APIs we have floating around attached to
devices.
You need to make one small important change. You need to take the POSIX
crap about enumerating things out and shoot it, bury it at a crossroads
and sprinkle holy water on it.
Drop the clockid_t and swap it for a file handle like a proper Unix or
Linux interface. The rest is much the same
fd = open /sys/class/timesource/[whatever]
various queries you may want to do to check the name etc
fclock_adjtime(fd, ...)
The posix interface is fundamentally flawed. It only works for staticly
enumerable objects. Unix avoided that forty years ago by making the
identifier a handle which immediately cures all your object lifetime
problems in one swoop.
Namespace -> file handle translations are dynamic, but once you have it
open you hold on to the same object, which means you can check what you
have.
Alan
^ permalink raw reply
* Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Alan Cox @ 2010-09-23 20:43 UTC (permalink / raw)
To: Christoph Lameter
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <alpine.DEB.2.00.1009231348150.2962-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
> Please do not introduce useless additional layers for clock sync. Load
> these ptp clocks like the other regular clock modules and make them sync
> system time like any other clock.
I don't think you understand PTP. PTP has masters, a system can need to
be honouring multiple conflicting masters at once.
> Really guys: I want a PTP solution! Now! And not some idiotic additional
> kernel layers that just pass bits around because its so much fun and
> screws up clock accurary in due to the latency noise introduced while
> having so much fun with the bits.
There are some interesting complications in putting a PTP sync
interface in kernel.
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: john stultz @ 2010-09-23 20:49 UTC (permalink / raw)
To: Alan Cox
Cc: Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra, linux-api,
devicetree-discuss, linux-kernel, David Miller, Thomas Gleixner,
netdev, Christoph Lameter, linuxppc-dev, Richard Cochran,
linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <20100923213654.0c64b047@lxorguk.ukuu.org.uk>
On Thu, 2010-09-23 at 21:36 +0100, Alan Cox wrote:
> > So as far as the POSIX standard is concerned, offering a clock id
> > to represent the PHC would be acceptable.
>
> But completely useless as you may have more than one entirely different
> time managed by PTP and in which you are not master but must work with
> the timebases provided.
I don't see how this is a problem, as it exposes the multiple hardware
clocks via different posix clock ids. So in the boundary clock case, you
can configure which side is the client and which side is the master in a
config file and the PTPd will appropriately steer them individually.
>
> > /sys/class/timesource/<name>/id
> > /sys/class/ptp/ptp_clock_X/id
> >
> > Note: I am not too sure that this is exactly what people imagined,
> > but it is my best understanding so far. I gleaned two
> > different ideas about where to offer the clock id. In order
> > to keep just one way, I will be happy to remove the less
> > popular one.
>
> I see no fix proposed for the race condition I pointed out. This doesn't
> work.
So, if I recall this was: "How do you keep the module from unloading
while its being used?"
There may need to be proper locking for unregistering the posix clock_id
on module unload, but I don't think we need a use-count to prevent the
module from being unloaded.
My question would be: How do we handle a USB network device ($14.99 now
with PTP!) being unplugged? We can't say "Sorry! That's in use!". So we
note the hardware is gone, and return the proper error code.
Or am I missing something else?
> > If the Linux system time is synchronized to the PHC via the PPS
>
> To which PHC we can have several
>
> > + Intel IXP465
> > - Auxiliary Slave/Master Mode Snapshot (optional interrupt)
> > - Target Time (optional interrupt)
>
> And about 40 already supported by char driver interface clocks and rtcs
> in the kernel...
And those char driver interfaces are all subtly different.
I actually recently submitted an RFC to expose the RTC devices via the
posix clock/timer interface, because working with the RTC hardware
device directly is terrible for managing alarm interrupts.
For instance, you easily run into the case where your TV recording
application programs an alarm to record your favorite show at 8pm. Then
your backup script programs an alarm to wake up at 2am to do your
nightly backups. Your box suspends and the next morning, you're missing
your favorite show!
> I'd say the inability to have multiple clocks and the race condition
> because of the clockid stuff leaves the proposal dead in the water.
>
> It also ignores the existing APIs we have floating around attached to
> devices.
>
> You need to make one small important change. You need to take the POSIX
> crap about enumerating things out and shoot it, bury it at a crossroads
> and sprinkle holy water on it.
We agree the list-by-name stuff isn't the way to go. :)
> Drop the clockid_t and swap it for a file handle like a proper Unix or
> Linux interface. The rest is much the same
>
> fd = open /sys/class/timesource/[whatever]
>
> various queries you may want to do to check the name etc
>
> fclock_adjtime(fd, ...)
>
>
> The posix interface is fundamentally flawed. It only works for staticly
> enumerable objects. Unix avoided that forty years ago by making the
> identifier a handle which immediately cures all your object lifetime
> problems in one swoop.
So, I don't really see how that's so different from what is being
proposed. The clock_id is dynamically assigned per registered clock, and
exposed via the sysfs interface from ptp hardware entry.
The only difference is the open/close reference counting, which I don't
think is necessary here (since we can't always keep the hardware from
going away).
thanks
-john
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Christoph Lameter @ 2010-09-23 20:49 UTC (permalink / raw)
To: john stultz
Cc: Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra, linux-api,
devicetree-discuss, linux-kernel, David Miller, netdev,
Thomas Gleixner, linuxppc-dev, Richard Cochran, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <1285273684.2587.92.camel@localhost.localdomain>
On Thu, 23 Sep 2010, john stultz wrote:
> > The HPET or pit timesource are also quite slow these days. You only need
> > access periodically to essentially tune the TSC ratio.
>
> If we're using the TSC, then we're not using the PTP clock as you
> suggest. Further the HPET and PIT aren't used to steer the system time
> when we are using the TSC as a clocksource. Its only used to calibrate
> the initial constant freq used by the timekeeping code (and if its
> non-constant, we throw it out).
There is no other scalable time source available for fast timer access
than the time stamp counter in the cpu. Other time source require
memory accesses which is inherently slower.
An accurate other time source is used to adjust this clock. NTP does that
via the clock interfaces from user space which has its problems with
accuracy. PTP can provide the network synced time access
that would a more accurate calibration of the time.
> 2) The way PTP clocks are steered to sync with network time causes their
> hardware freq to actually change. Since these adjustments are done on
> the hardware clock level, and not on the system time level, the
> adjustments to sync the system time/freq would then be made incorrect by
> PTP hardware adjustments.
Right. So use these as a way to fine tune the TSC clock (and thereby the
system time).
> 3) Further, the PTP hardware counter can be simply set to a new offset
> to put it in line with the network time. This could cause trouble with
> timekeeping much like unsynced TSCs do.
You can do the same for system time.
> Now, what you seem to be suggesting is to use the TSC (or whatever
> clocksource the system time is using) but to steer the system time using
> the PTP clock. This is actually what is being proposed, however, the
> steering is done in userland. This is due to the fact that there are two
> components to the steering, 1) adjusting the PTP clock hardware to
> network time and 2) adjusting the system time to the PTP hardware. By
> exposing the PTP clock to userland via the posix clocks interface, we
> allow this to easily be done.
Userland code would introduce latencies that would make sub microsecond
time sync very difficult.
> > We can switch underlying clocks for system time already. We can adapt to a
> > different hw frequency.
>
> Actually no. The timekeeping code requires a fixed freq counter. Dealing
> with hardware freq changes is difficult, because error is introduced by
> the latency between when the freq changes and when the timekeeping code
> is notified of it. So the system treats the hardware counters as fixed
> freq. Now, hardware does vary freq ever so slightly as thermal
> conditions change, but this is addressed in userland and corrected via
> adjtimex.
Acadmic hair splitting? I have repeatedly switched between different
clocks on various systems. So its difficult but we do it?
> Unnecessary layers? Where? This approach has less in-kernel layers, as
> it exposes the PTP clock to userland, instead of trying to layer things
> on top of it and stretching the system time abstraction to cover it.
You dont need the user APIs if you directly use the PTP time source to
steer the system clock. In fact I think you have to do it in kernel space
since user space latencies will degrade accuracy otherwise.
> I've argued through the approach trying to keep it all internal to the
> kernel, but to do so would be anything but trivial. Further, there's the
> case of master-clocks, where the PTP hardware must be synced to system
> time, instead of the other way around. And then there's the case of
> boundary-clocks, which may have multiple PTP hardware clocks that have
> to be synced.
Ok maybe we need some sort of control interface to manage the clock like
the others have.
> I think exposing this through the posix clock interface is really the
> best approach. Its not a static clockid, so its not something most apps
> will ever have to deal with, but it allows the few apps that really need
> to have access to the PTP clock hardware can do so in a clean way.
It implies clock tuning in userspace for a potential sub microsecond
accurate clock. The clock accuracy will be limited by user space
latencies and noise. You wont be able to discipline the system clock
accurately.
The posix clocks today assumes one notion of real "time" in the kernel.
All clocks increase in lockstep (aside from offset updates). This approach
here result in multiple notions of "time" increasing at various speeds.
And it implies that someone is user space is trying to tinker around with
extremely low latencies using system call APIs that take much longer than
these intervals to process the data.
^ permalink raw reply
* [PATCH] de2104x: disable autonegotiation on broken hardware
From: Ondrej Zary @ 2010-09-23 20:59 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Kernel development list
At least on older 21041-AA chips (mine is rev. 11), TP duplex autonegotiation
causes the card not to work at all (link is up but no packets are transmitted).
de4x5 disables autonegotiation completely. But it seems to work on newer
(21041-PA rev. 21) so disable it only on rev<20 chips.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.36-rc3-orig/drivers/net/tulip/de2104x.c 2010-08-29 17:36:04.000000000 +0200
+++ linux-2.6.36-rc3/drivers/net/tulip/de2104x.c 2010-09-24 00:27:41.000000000 +0200
@@ -364,6 +364,8 @@ static u16 t21040_csr15[] = { 0, 0, 0x00
/* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/
static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
+/* If on-chip autonegotiation is broken, use half-duplex (FF3F) instead */
+static u16 t21041_csr14_brk[] = { 0xFF3F, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
static u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, };
@@ -1911,8 +1913,14 @@ fill_defaults:
for (i = 0; i < DE_MAX_MEDIA; i++) {
if (de->media[i].csr13 == 0xffff)
de->media[i].csr13 = t21041_csr13[i];
- if (de->media[i].csr14 == 0xffff)
- de->media[i].csr14 = t21041_csr14[i];
+ if (de->media[i].csr14 == 0xffff) {
+ /* autonegotiation is broken at least on some chip
+ revisions - rev. 0x21 works, 0x11 does not */
+ if (de->pdev->revision < 0x20)
+ de->media[i].csr14 = t21041_csr14_brk[i];
+ else
+ de->media[i].csr14 = t21041_csr14[i];
+ }
if (de->media[i].csr15 == 0xffff)
de->media[i].csr15 = t21041_csr15[i];
}
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH] de2104x: disable autonegotiation on broken hardware
From: Jeff Garzik @ 2010-09-23 21:03 UTC (permalink / raw)
To: Ondrej Zary; +Cc: netdev, Kernel development list
In-Reply-To: <201009232259.20261.linux@rainbow-software.org>
On Thu, Sep 23, 2010 at 4:59 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> At least on older 21041-AA chips (mine is rev. 11), TP duplex autonegotiation
> causes the card not to work at all (link is up but no packets are transmitted).
>
> de4x5 disables autonegotiation completely. But it seems to work on newer
> (21041-PA rev. 21) so disable it only on rev<20 chips.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>
> --- linux-2.6.36-rc3-orig/drivers/net/tulip/de2104x.c 2010-08-29 17:36:04.000000000 +0200
> +++ linux-2.6.36-rc3/drivers/net/tulip/de2104x.c 2010-09-24 00:27:41.000000000 +0200
> @@ -364,6 +364,8 @@ static u16 t21040_csr15[] = { 0, 0, 0x00
> /* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/
> static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
> static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
> +/* If on-chip autonegotiation is broken, use half-duplex (FF3F) instead */
> +static u16 t21041_csr14_brk[] = { 0xFF3F, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
> static u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, };
>
>
> @@ -1911,8 +1913,14 @@ fill_defaults:
> for (i = 0; i < DE_MAX_MEDIA; i++) {
> if (de->media[i].csr13 == 0xffff)
> de->media[i].csr13 = t21041_csr13[i];
> - if (de->media[i].csr14 == 0xffff)
> - de->media[i].csr14 = t21041_csr14[i];
> + if (de->media[i].csr14 == 0xffff) {
> + /* autonegotiation is broken at least on some chip
> + revisions - rev. 0x21 works, 0x11 does not */
> + if (de->pdev->revision < 0x20)
> + de->media[i].csr14 = t21041_csr14_brk[i];
> + else
> + de->media[i].csr14 = t21041_csr14[i];
> + }
Interesting... I never knew about that quirk.
Acked-by: Jeff Garzik <jgarzik@redhat.com>
^ permalink raw reply
* [PATCH] netfilter: fix kconfig unmet dependency warning
From: Randy Dunlap @ 2010-09-23 21:03 UTC (permalink / raw)
To: netdev; +Cc: davem, netfilter-devel, Patrick McHardy
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix netfilter kconfig unmet dependencies warning & spell out
"compatible" while there.
warning: (IP_NF_TARGET_TTL && NET && INET && NETFILTER && IP_NF_IPTABLES && NETFILTER_ADVANCED || IP6_NF_TARGET_HL && NET && INET && IPV6 && NETFILTER && IP6_NF_IPTABLES && NETFILTER_ADVANCED) selects NETFILTER_XT_TARGET_HL which has unmet direct dependencies ((IP_NF_MANGLE || IP6_NF_MANGLE) && NETFILTER_ADVANCED)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
net/ipv4/netfilter/Kconfig | 4 ++--
net/ipv6/netfilter/Kconfig | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- linux-next-20100921.orig/net/ipv4/netfilter/Kconfig
+++ linux-next-20100921/net/ipv4/netfilter/Kconfig
@@ -324,10 +324,10 @@ config IP_NF_TARGET_ECN
config IP_NF_TARGET_TTL
tristate '"TTL" target support'
- depends on NETFILTER_ADVANCED
+ depends on NETFILTER_ADVANCED && IP_NF_MANGLE
select NETFILTER_XT_TARGET_HL
---help---
- This is a backwards-compat option for the user's convenience
+ This is a backwards-compatible option for the user's convenience
(e.g. when running oldconfig). It selects
CONFIG_NETFILTER_XT_TARGET_HL.
--- linux-next-20100921.orig/net/ipv6/netfilter/Kconfig
+++ linux-next-20100921/net/ipv6/netfilter/Kconfig
@@ -132,10 +132,10 @@ config IP6_NF_MATCH_RT
# The targets
config IP6_NF_TARGET_HL
tristate '"HL" hoplimit target support'
- depends on NETFILTER_ADVANCED
+ depends on NETFILTER_ADVANCED && IP6_NF_MANGLE
select NETFILTER_XT_TARGET_HL
---help---
- This is a backwards-compat option for the user's convenience
+ This is a backwards-compatible option for the user's convenience
(e.g. when running oldconfig). It selects
CONFIG_NETFILTER_XT_TARGET_HL.
^ permalink raw reply
* Re: [PATCH] de2104x: disable autonegotiation on broken hardware
From: Ondrej Zary @ 2010-09-23 21:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Kernel development list
In-Reply-To: <AANLkTikwXyr4pH5rqkoXpiYvkvpLc7s8tq-EwmM1+r7m@mail.gmail.com>
On Thursday 23 September 2010 23:03:13 Jeff Garzik wrote:
> On Thu, Sep 23, 2010 at 4:59 PM, Ondrej Zary <linux@rainbow-software.org>
wrote:
> > At least on older 21041-AA chips (mine is rev. 11), TP duplex
> > autonegotiation causes the card not to work at all (link is up but no
> > packets are transmitted).
> >
> > de4x5 disables autonegotiation completely. But it seems to work on newer
> > (21041-PA rev. 21) so disable it only on rev<20 chips.
> >
> > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> >
> > --- linux-2.6.36-rc3-orig/drivers/net/tulip/de2104x.c 2010-08-29
> > 17:36:04.000000000 +0200 +++ linux-2.6.36-rc3/drivers/net/tulip/de2104x.c
> > 2010-09-24 00:27:41.000000000 +0200 @@ -364,6 +364,8 @@ static u16
> > t21040_csr15[] = { 0, 0, 0x00
> > /* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/
> > static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
> > static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
> > +/* If on-chip autonegotiation is broken, use half-duplex (FF3F) instead
> > */ +static u16 t21041_csr14_brk[] = { 0xFF3F, 0xF7FD, 0xF7FD, 0x6F3F,
> > 0x6F3D, }; static u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008,
> > 0x0008, };
> >
> >
> > @@ -1911,8 +1913,14 @@ fill_defaults:
> > for (i = 0; i < DE_MAX_MEDIA; i++) {
> > if (de->media[i].csr13 == 0xffff)
> > de->media[i].csr13 = t21041_csr13[i];
> > - if (de->media[i].csr14 == 0xffff)
> > - de->media[i].csr14 = t21041_csr14[i];
> > + if (de->media[i].csr14 == 0xffff) {
> > + /* autonegotiation is broken at least on some
> > chip + revisions - rev. 0x21 works, 0x11 does
> > not */ + if (de->pdev->revision < 0x20)
> > + de->media[i].csr14 = t21041_csr14_brk[i];
> > + else
> > + de->media[i].csr14 = t21041_csr14[i];
> > + }
>
> Interesting... I never knew about that quirk.
This errata document says that autonegotiation is somehow broken but it does
not specify it further:
http://ftp.nluug.nl/ftp/ftp/pub/os/NetBSD/misc/dec-docs/ec-qd2ma-te.ps.gz
--
Ondrej Zary
^ permalink raw reply
* [PATCH] net: reset skb queue mapping when rx'ing over tunnel
From: Tom Herbert @ 2010-09-23 21:19 UTC (permalink / raw)
To: netdev, davem; +Cc: chavey
Reset queue mapping when an skb is reentering the stack via a tunnel.
On second pass, the queue mapping from the original device is no
longer valid.
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/include/net/dst.h b/include/net/dst.h
index 81d1413..0238650 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -242,6 +242,7 @@ static inline void skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
dev->stats.rx_packets++;
dev->stats.rx_bytes += skb->len;
skb->rxhash = 0;
+ skb_set_queue_mapping(skb, 0);
skb_dst_drop(skb);
nf_reset(skb);
}
^ permalink raw reply related
* Re: [PATCH 1/2 -next] r8169: allocate with GFP_KERNEL flag when able to sleep
From: Francois Romieu @ 2010-09-23 21:20 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev
In-Reply-To: <1285243291-4520-1-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> :
> We have fedora bug report where driver fail to initialize after
> suspend/resume because of memory allocation errors:
> https://bugzilla.redhat.com/show_bug.cgi?id=629158
>
> To fix use GFP_KERNEL allocation where possible.
Feel free to add a Acked-by: Francois Romieu <romieu@fr.zoreil.com>
as soon as it will have been explicitely reported to improve the
situation (it is not clear in the PR above).
--
Ueimor
^ permalink raw reply
* Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Christian Riesch @ 2010-09-23 21:26 UTC (permalink / raw)
To: Alan Cox
Cc: Christoph Lameter, Richard Cochran, linux-kernel,
devicetree-discuss, linux-api, linux-arm-kernel, linuxppc-dev,
netdev, Arnd Bergmann, David Miller, John Stultz,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <20100923214359.3f287b11@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> Please do not introduce useless additional layers for clock sync. Load
>> these ptp clocks like the other regular clock modules and make them sync
>> system time like any other clock.
>
> I don't think you understand PTP. PTP has masters, a system can need to
> be honouring multiple conflicting masters at once.
AFAIK the master's should not be conflicting. The Best Master Clock
algorithm (BMC) defined in IEEE1588 selects the best master clock. This
clock distributes its notion of time on the network while the other
masters, that is the other clocks/nodes that are configured to
potentially become a master, keep quiet. So usually we will only have
one source of time (the master clock selected by the BMC) and we will
steer our single PHC (PTP hardware clock) to follow this master (Of
course there may be use-cases that require more than one PTP clock,
e.g., for research purposes).
However, if the clock selected by the BMC is switched off, loses its
network connection..., the second best clock is selected by the BMC and
becomes master. This clock may be less accurate and thus our slave clock
has to switch from one notion of time to another. Is that the conflict
you mentioned?
Christian
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Alan Cox @ 2010-09-23 21:30 UTC (permalink / raw)
To: john stultz
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Christoph Lameter,
David Miller, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <1285274952.2587.113.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
O> I don't see how this is a problem, as it exposes the multiple hardware
> clocks via different posix clock ids. So in the boundary clock case, you
> can configure which side is the client and which side is the master in a
> config file and the PTPd will appropriately steer them individually.
They may all be slaves - that means you can't treat them as part of
system time.
>
> on module unload, but I don't think we need a use-count to prevent the
> module from being unloaded.
>
> My question would be: How do we handle a USB network device ($14.99 now
> with PTP!) being unplugged? We can't say "Sorry! That's in use!". So we
> note the hardware is gone, and return the proper error code.
>
> Or am I missing something else?
Open list
Oh number 31 appears to be the device I want
Close list
USB unplugged
Random other device plugged
clock_op(31, ....)
Oh bugger I've just reprogrammed the wrong time source.
We don't have stop the device being removed, instead of a disaster you get
clock_op(fd, blah)
-ENODEV
which btw is how just about everything else USB works when you pull the
hardware.
> > And about 40 already supported by char driver interface clocks and rtcs
> > in the kernel...
>
> And those char driver interfaces are all subtly different.
>
> I actually recently submitted an RFC to expose the RTC devices via the
> posix clock/timer interface, because working with the RTC hardware
> device directly is terrible for managing alarm interrupts.
Given that driver interfaces are sane and posix clock/timer interfaces
have totally broken enumeration maybe you have it backwards. But if you
follow through to my proposal maybe there is a saner answer still
> For instance, you easily run into the case where your TV recording
> application programs an alarm to record your favorite show at 8pm. Then
> your backup script programs an alarm to wake up at 2am to do your
> nightly backups. Your box suspends and the next morning, you're missing
> your favorite show!
Poor resource management, and yes I'd agree you want a sensible interface.
> > Drop the clockid_t and swap it for a file handle like a proper Unix or
> > Linux interface. The rest is much the same
> >
> > fd = open /sys/class/timesource/[whatever]
> >
> > various queries you may want to do to check the name etc
> >
> > fclock_adjtime(fd, ...)
> >
> >
> > The posix interface is fundamentally flawed. It only works for staticly
> > enumerable objects. Unix avoided that forty years ago by making the
> > identifier a handle which immediately cures all your object lifetime
> > problems in one swoop.
>
> So, I don't really see how that's so different from what is being
> proposed. The clock_id is dynamically assigned per registered clock, and
> exposed via the sysfs interface from ptp hardware entry.
>
> The only difference is the open/close reference counting, which I don't
> think is necessary here (since we can't always keep the hardware from
> going away).
It is absolutely neccessary in order that you can be sure that two calls
actually relate to the *same* device. It's as fundamental as the
difference betweeh chmod and fchmod although with the added ugliness of
some random numeric identifier stuck in the middle.
It also btw makes it much easier to fix up the existing random collection
of /dev/rtc devices - because you can open them and issue fclock_adjtime
if we are careful how we do it and it makes sense.
Alan
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] e1000: use work queues
From: David Miller @ 2010-09-23 21:34 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, jesse.brandeburg
In-Reply-To: <20100923042126.11798.49675.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 21:22:17 -0700
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> E1000 is using several timers that in a follow on patch
> will need to acquire the rtnl_lock in order to be safe.
>
> This patch moves the timer bodies into work queues which
> will allow the next patch to add rtnl_lock.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] e1000: fix occasional panic on unload
From: David Miller @ 2010-09-23 21:34 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, jesse.brandeburg
In-Reply-To: <20100923042240.11798.65680.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 21:22:42 -0700
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Net drivers in general have an issue where timers fired
> by mod_timer or work threads with schedule_work are running
> outside of the rtnl_lock.
>
> With no other lock protection these routines are vulnerable
> to races with driver unload or reset paths.
>
> The longer term solution to this might be a redesign with
> safer locks being taken in the driver to guarantee no
> reentrance, but for now a safe and effective fix is
> to take the rtnl_lock in these routines.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ 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;
as well as URLs for NNTP newsgroup(s).