Dear RT folks!
I'm pleased to announce the v3.10.6-rt3 patch set.
Changes since v3.10.6-rt2
- the queue can be imported with git quiltimport
- powerpc compiles again. Thanks to Paul Gortmaker for the patch.
- added three patches from v3.8 which fall the wagon on their way to
3.10. One of them enables RT-FULL on ARM :)
- removed all cpsw patches from the queue. They made it upstream. My
nfsboot setup seems not to work, lets look at this later.
- make arm/spear compile. Thanks to Felipe Balbi for the patch.
- Add a patch from Corey Minyard to no longer use deprecated
CONFIG_NO_HZ.
- add the one patch which I added to the last 3.8-rt to get get list_bl
work again on !SMP && !DEBUG_SPINLOCK
- Spell "preemptible" properly in "Preemptible Kernel (Basic RT)" menu
item. Thanks to Uwe Kleine-König for the patch.
- a patch from John Kacur to avoid a warning in the hpsa.
- a patch for the ppc5200 where the compiler thinks a variable isn't
initialized and stops compililing due to -Werror
Known issues:
- SLAB support not working
- The cpsw network driver shows some issues.
- ARM & PPC don't fall apart once booted. More testing doesn't
hurt.
- bcache with CONFIG_DEBUG_LOCK_ALLOC enabled does not compile.
The delta patch against v3.10.6-rt2 is appended below and can be found
here:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/incr/patch-3.10.6-rt2-rt3.patch.xz
The RT patch against 3.10.6 can be found here:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.6-rt3.patch.xz
The split quilt queue is available at:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patches-3.10.6-rt3.tar.xz
Sebastian
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2ef0b69..b34ff02 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -19,6 +19,7 @@ config ARM
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select HARDIRQS_SW_RESEND
+ select IRQ_FORCED_THREADING
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 1f2740e..b32b043 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -118,7 +118,8 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
continue;
}
- err = request_irq(irq, handler, IRQF_NOBALANCING, "arm-pmu",
+ err = request_irq(irq, handler,
+ IRQF_NOBALANCING | IRQF_NO_THREAD, "arm-pmu",
cpu_pmu);
if (err) {
pr_err("unable to request IRQ%d for ARM PMU counters\n",
diff --git a/arch/arm/mach-spear/platsmp.c b/arch/arm/mach-spear/platsmp.c
index 382eef6..ec5437d 100644
--- a/arch/arm/mach-spear/platsmp.c
+++ b/arch/arm/mach-spear/platsmp.c
@@ -20,7 +20,7 @@
#include <mach/spear.h>
#include "generic.h"
-static DEFINE_SPINLOCK(boot_lock);
+static DEFINE_RAW_SPINLOCK(boot_lock);
static void __iomem *scu_base = IOMEM(VA_SCU_BASE);
diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index 2469444..f50711f 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -92,8 +92,7 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
#define TIF_SIGPENDING 1 /* signal pending */
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
-#define TIF_POLLING_NRFLAG 3 /* true if poll_idle() is polling
- TIF_NEED_RESCHED */
+#define TIF_NEED_RESCHED_LAZY 3 /* lazy rescheduling necessary */
#define TIF_32BIT 4 /* 32 bit binary */
#define TIF_PERFMON_WORK 5 /* work for pfm_handle_work() */
#define TIF_PERFMON_CTXSW 6 /* perfmon needs ctxsw calls */
@@ -109,7 +108,8 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_EMULATE_STACK_STORE 16 /* Is an instruction emulation
for stack store? */
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
-#define TIF_NEED_RESCHED_LAZY 18 /* lazy rescheduling necessary */
+#define TIF_POLLING_NRFLAG 18 /* true if poll_idle() is polling
+ TIF_NEED_RESCHED */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index b89ef65..b69221b 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -373,8 +373,9 @@ static int mpc52xx_irqhost_map(struct irq_domain *h, unsigned int virq,
case MPC52xx_IRQ_L1_PERP: irqchip = &mpc52xx_periph_irqchip; break;
case MPC52xx_IRQ_L1_SDMA: irqchip = &mpc52xx_sdma_irqchip; break;
case MPC52xx_IRQ_L1_CRIT:
+ default:
pr_warn("%s: Critical IRQ #%d is unsupported! Nopping it.\n",
- __func__, l2irq);
+ __func__, l1irq);
irq_set_chip(virq, &no_irq_chip);
return 0;
}
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
index 1e12108..806cbbd 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -43,6 +43,7 @@ static irqreturn_t timebase_interrupt(int irq, void *dev)
static struct irqaction tbint_irqaction = {
.handler = timebase_interrupt,
+ .flags = IRQF_NO_THREAD,
.name = "tbint",
};
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index d4fa03f..5e6ff38 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -120,6 +120,7 @@ static irqreturn_t cpm_error_interrupt(int irq, void *dev)
static struct irqaction cpm_error_irqaction = {
.handler = cpm_error_interrupt,
+ .flags = IRQF_NO_THREAD,
.name = "error",
};
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 469eb6c..aaf4b9b 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1408,7 +1408,7 @@ static inline int mce_notify_work_init(void) { return 0; }
*/
int mce_notify_irq(void)
{
- if (test_and_clear_bit(0, &mce_need_notify)) {
+ if (test_and_clear_bit(0, &mce_need_notify)) {
mce_notify_work();
return 1;
}
diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c
index 70d1920..31bbbca 100644
--- a/drivers/net/ethernet/ti/cpmac.c
+++ b/drivers/net/ethernet/ti/cpmac.c
@@ -1172,8 +1172,8 @@ static int cpmac_probe(struct platform_device *pdev)
snprintf(priv->phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT,
mdio_bus_id, phy_id);
- priv->phy = phy_connect(dev, priv->phy_name, cpmac_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ priv->phy = phy_connect(dev, priv->phy_name, cpmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
if (IS_ERR(priv->phy)) {
if (netif_msg_drv(priv))
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c0dea7c..d1a769f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -490,7 +490,7 @@ void cpsw_rx_handler(void *token, int len, int status)
skb_put(skb, len);
cpts_rx_timestamp(priv->cpts, skb);
skb->protocol = eth_type_trans(skb, ndev);
- netif_rx(skb);
+ netif_receive_skb(skb);
priv->stats.rx_bytes += len;
priv->stats.rx_packets++;
} else {
@@ -507,24 +507,19 @@ void cpsw_rx_handler(void *token, int len, int status)
static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
- unsigned long flags;
u32 rx, tx, rx_thresh;
- spin_lock_irqsave(&priv->lock, flags);
rx_thresh = __raw_readl(&priv->wr_regs->rx_thresh_stat);
rx = __raw_readl(&priv->wr_regs->rx_stat);
tx = __raw_readl(&priv->wr_regs->tx_stat);
- if (!rx_thresh && !rx && !tx) {
- spin_unlock_irqrestore(&priv->lock, flags);
+ if (!rx_thresh && !rx && !tx)
return IRQ_NONE;
- }
cpsw_intr_disable(priv);
if (priv->irq_enabled == true) {
cpsw_disable_irq(priv);
priv->irq_enabled = false;
}
- spin_unlock_irqrestore(&priv->lock, flags);
if (netif_running(priv->ndev)) {
napi_schedule(&priv->napi);
@@ -546,9 +541,7 @@ static int cpsw_poll(struct napi_struct *napi, int budget)
{
struct cpsw_priv *priv = napi_to_priv(napi);
int num_tx, num_rx;
- unsigned long flags;
- spin_lock_irqsave(&priv->lock, flags);
num_tx = cpdma_chan_process(priv->txch, 128);
if (num_tx)
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
@@ -824,7 +817,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
- &cpsw_adjust_link, 0, slave->data->phy_if);
+ &cpsw_adjust_link, slave->data->phy_if);
if (IS_ERR(slave->phy)) {
dev_err(priv->dev, "phy %s not found on slave %d\n",
slave->data->phy_id, slave->slave_num);
@@ -1293,7 +1286,7 @@ static inline int cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
}
static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
- unsigned short vid)
+ __be16 proto, u16 vid)
{
struct cpsw_priv *priv = netdev_priv(ndev);
@@ -1305,7 +1298,7 @@ static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
}
static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
- unsigned short vid)
+ __be16 proto, u16 vid)
{
struct cpsw_priv *priv = netdev_priv(ndev);
int ret;
@@ -1466,12 +1459,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
if (of_property_read_u32(node, "active_slave", &prop)) {
pr_err("Missing active_slave property in the DT.\n");
- if (of_property_read_u32(node, "cpts_active_slave", &prop)) {
- ret = -EINVAL;
- goto error_ret;
- } else {
- pr_err("Using old cpts_active_slave as fallback.\n");
- }
+ ret = -EINVAL;
+ goto error_ret;
}
data->active_slave = prop;
@@ -1644,7 +1633,7 @@ static int cpsw_probe_dual_emac(struct platform_device *pdev,
priv_sl2->irqs_table[i] = priv->irqs_table[i];
priv_sl2->num_irqs = priv->num_irqs;
}
- ndev->features |= NETIF_F_HW_VLAN_FILTER;
+ ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
ndev->netdev_ops = &cpsw_netdev_ops;
SET_ETHTOOL_OPS(ndev, &cpsw_ethtool_ops);
@@ -1883,7 +1872,7 @@ static int cpsw_probe(struct platform_device *pdev)
k++;
}
- ndev->features |= NETIF_F_HW_VLAN_FILTER;
+ ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
ndev->netdev_ops = &cpsw_netdev_ops;
SET_ETHTOOL_OPS(ndev, &cpsw_ethtool_ops);
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 5aa9e4d..860e15d 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1600,7 +1600,7 @@ static int emac_dev_open(struct net_device *ndev)
if (priv->phy_id && *priv->phy_id) {
priv->phydev = phy_connect(ndev, priv->phy_id,
- &emac_adjust_link, 0,
+ &emac_adjust_link,
PHY_INTERFACE_MODE_MII);
if (IS_ERR(priv->phydev)) {
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..4e19267 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h, struct CommandList *c)
c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1);
if (likely(h->msix_vector))
c->Header.ReplyQueue =
- smp_processor_id() % h->nreply_queues;
+ raw_smp_processor_id() % h->nreply_queues;
}
}
diff --git a/include/linux/list_bl.h b/include/linux/list_bl.h
index 0ab40b6..d8876a0 100644
--- a/include/linux/list_bl.h
+++ b/include/linux/list_bl.h
@@ -131,8 +131,10 @@ static inline void hlist_bl_lock(struct hlist_bl_head *b)
bit_spin_lock(0, (unsigned long *)b);
#else
raw_spin_lock(&b->lock);
+#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__set_bit(0, (unsigned long *)b);
#endif
+#endif
}
static inline void hlist_bl_unlock(struct hlist_bl_head *b)
@@ -140,7 +142,9 @@ static inline void hlist_bl_unlock(struct hlist_bl_head *b)
#ifndef CONFIG_PREEMPT_RT_BASE
__bit_spin_unlock(0, (unsigned long *)b);
#else
+#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
__clear_bit(0, (unsigned long *)b);
+#endif
raw_spin_unlock(&b->lock);
#endif
}
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index 38cecfe..11dbe26 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -70,7 +70,7 @@ config PREEMPT_RTB
select PREEMPT_RT_BASE
help
This option is basically the same as (Low-Latency Desktop) but
- enables changes which are preliminary for the full preemptiple
+ enables changes which are preliminary for the full preemptible
RT kernel.
config PREEMPT_RT_FULL
diff --git a/kernel/softirq.c b/kernel/softirq.c
index db2fe2b..3298e55 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -64,7 +64,7 @@ char *softirq_to_name[NR_SOFTIRQS] = {
"TASKLET", "SCHED", "HRTIMER", "RCU"
};
-#ifdef CONFIG_NO_HZ
+#ifdef CONFIG_NO_HZ_COMMON
# ifdef CONFIG_PREEMPT_RT_FULL
struct softirq_runner {
@@ -151,7 +151,7 @@ void softirq_check_pending_idle(void)
}
# endif
-#else /* !NO_HZ */
+#else /* !CONFIG_NO_HZ_COMMON */
static inline void softirq_set_runner(unsigned int sirq) { }
static inline void softirq_clr_runner(unsigned int sirq) { }
#endif
diff --git a/localversion-rt b/localversion-rt
index c3054d0..1445cd6 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt2
+-rt3
On Mon, 12 Aug 2013 18:34:13 +0200
Sebastian Andrzej Siewior <[email protected]> wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.10.6-rt3 patch set.
Does this mean that I can drop 3.6-rt in favor of 3.8-rt?
I'm just about finished with a 3.6 stable, which I'll finish, add -rt
to it, and then call it "unsupported" after that. Well, I may take bug
fixes if people find any in the near future.
I'm behind on 3.4-rt, 3.2-rt and of course 3.0-rt. Hopefully, I'll get
them all out this week.
-- Steve
On Mon, Aug 12, 2013 at 3:48 PM, Steven Rostedt <[email protected]> wrote:
> On Mon, 12 Aug 2013 18:34:13 +0200
> Sebastian Andrzej Siewior <[email protected]> wrote:
>
>> Dear RT folks!
>>
>> I'm pleased to announce the v3.10.6-rt3 patch set.
>
>
> Does this mean that I can drop 3.6-rt in favor of 3.8-rt?
I'd guess that the trade-off would be 3.0-rt against 3.8-rt.
The above comment assumes 3.0 is aged out vs. 3.6 kernel.
>
> I'm just about finished with a 3.6 stable, which I'll finish, add -rt
> to it, and then call it "unsupported" after that. Well, I may take bug
> fixes if people find any in the near future.
>
> I'm behind on 3.4-rt, 3.2-rt and of course 3.0-rt. Hopefully, I'll get
> them all out this week.
I expect that the 3.10-rt kernel will replace the older RT kernels.
>
> -- Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 12 Aug 2013 20:47:18 -0400
Paul Gortmaker <[email protected]> wrote:
> On Mon, Aug 12, 2013 at 3:48 PM, Steven Rostedt <[email protected]> wrote:
> > On Mon, 12 Aug 2013 18:34:13 +0200
> > Sebastian Andrzej Siewior <[email protected]> wrote:
> >
> >> Dear RT folks!
> >>
> >> I'm pleased to announce the v3.10.6-rt3 patch set.
> >
> >
> > Does this mean that I can drop 3.6-rt in favor of 3.8-rt?
>
> I'd guess that the trade-off would be 3.0-rt against 3.8-rt.
> The above comment assumes 3.0 is aged out vs. 3.6 kernel.
Not at all. I've always said that I would support -rt as long as the
base was supported by the official stable. 3.6 is not supported, and I
only supported it because it was the "latest" stable -rt. When 3.8-rt
comes out, it would also be the latest. But it too is not supported by
the official stable release. I'll only be doing that one until 3.10
becomes stable again. Luckily, 3.8 is being supported by Kamal, and
I'll probably just base my work off of his.
3.0-rt wont last long, as IIRC, Greg will be letting that go off to
ashes in a few months.
>
> >
> > I'm just about finished with a 3.6 stable, which I'll finish, add -rt
> > to it, and then call it "unsupported" after that. Well, I may take bug
> > fixes if people find any in the near future.
> >
> > I'm behind on 3.4-rt, 3.2-rt and of course 3.0-rt. Hopefully, I'll get
> > them all out this week.
>
> I expect that the 3.10-rt kernel will replace the older RT kernels.
No, it will just enter the realm of the official stable releases.
-- Steve
On 08/13/2013 02:47 AM, Paul Gortmaker wrote:
> On Mon, Aug 12, 2013 at 3:48 PM, Steven Rostedt <[email protected]> wrote:
>> On Mon, 12 Aug 2013 18:34:13 +0200
>> Sebastian Andrzej Siewior <[email protected]> wrote:
>>
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.10.6-rt3 patch set.
>>
>> Does this mean that I can drop 3.6-rt in favor of 3.8-rt?
>
> I'd guess that the trade-off would be 3.0-rt against 3.8-rt.
> The above comment assumes 3.0 is aged out vs. 3.6 kernel.
>
>> I'm just about finished with a 3.6 stable, which I'll finish, add -rt
>> to it, and then call it "unsupported" after that. Well, I may take bug
>> fixes if people find any in the near future.
>>
>> I'm behind on 3.4-rt, 3.2-rt and of course 3.0-rt. Hopefully, I'll get
>> them all out this week.
>
> I expect that the 3.10-rt kernel will replace the older RT kernels.
We should not forget 3.2 that will be maintained until March 2016. Thus,
let's focus on 3.2 and 3.10 (maintained until August 2015) and abandon
all other 3.x RT versions.
-Carsten.
On Tue, 13 Aug 2013, Carsten Emde wrote:
> On 08/13/2013 02:47 AM, Paul Gortmaker wrote:
> > On Mon, Aug 12, 2013 at 3:48 PM, Steven Rostedt <[email protected]> wrote:
> > > I'm behind on 3.4-rt, 3.2-rt and of course 3.0-rt. Hopefully, I'll get
> > > them all out this week.
> >
> > I expect that the 3.10-rt kernel will replace the older RT kernels.
>
> We should not forget 3.2 that will be maintained until March
> 2016. Thus, let's focus on 3.2 and 3.10 (maintained until August
> 2015) and abandon all other 3.x RT versions.
Yes, please. We need all man power on 3.10 and let's keep 3.2 as a
long term supported version along with the nice work from the debian
kernel team.
Thanks,
tglx
On Tue, 13 Aug 2013 12:54:26 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:
> On Tue, 13 Aug 2013, Carsten Emde wrote:
> > On 08/13/2013 02:47 AM, Paul Gortmaker wrote:
> > > On Mon, Aug 12, 2013 at 3:48 PM, Steven Rostedt <[email protected]> wrote:
> > > > I'm behind on 3.4-rt, 3.2-rt and of course 3.0-rt. Hopefully, I'll get
> > > > them all out this week.
> > >
> > > I expect that the 3.10-rt kernel will replace the older RT kernels.
> >
> > We should not forget 3.2 that will be maintained until March
> > 2016. Thus, let's focus on 3.2 and 3.10 (maintained until August
> > 2015) and abandon all other 3.x RT versions.
>
> Yes, please. We need all man power on 3.10 and let's keep 3.2 as a
> long term supported version along with the nice work from the debian
> kernel team.
>
Unfortunately, the company that is paying me, is interested in some of
the other versions.
-- Steve
On 08/12/2013 09:34 AM, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.10.6-rt3 patch set.
I'm getting this when trying to build:
drivers/md/bcache/request.c: In function 'cached_dev_write_complete':
drivers/md/bcache/request.c:1008:2: error: implicit declaration of
function 'up_read_non_owner' [-Werror=implicit-function-declaration]
up_read_non_owner(&dc->writeback_lock);
^
drivers/md/bcache/request.c: In function 'request_write':
drivers/md/bcache/request.c:1034:2: error: implicit declaration of
function 'down_read_non_owner' [-Werror=implicit-function-declaration]
down_read_non_owner(&dc->writeback_lock);
^
cc1: some warnings being treated as errors
Does not look like *_read_non_owner exist in rwsem_rt.h...
-- Fernando
> Changes since v3.10.6-rt2
> - the queue can be imported with git quiltimport
> - powerpc compiles again. Thanks to Paul Gortmaker for the patch.
> - added three patches from v3.8 which fall the wagon on their way to
> 3.10. One of them enables RT-FULL on ARM :)
> - removed all cpsw patches from the queue. They made it upstream. My
> nfsboot setup seems not to work, lets look at this later.
> - make arm/spear compile. Thanks to Felipe Balbi for the patch.
> - Add a patch from Corey Minyard to no longer use deprecated
> CONFIG_NO_HZ.
> - add the one patch which I added to the last 3.8-rt to get get list_bl
> work again on !SMP && !DEBUG_SPINLOCK
> - Spell "preemptible" properly in "Preemptible Kernel (Basic RT)" menu
> item. Thanks to Uwe Kleine-König for the patch.
> - a patch from John Kacur to avoid a warning in the hpsa.
> - a patch for the ppc5200 where the compiler thinks a variable isn't
> initialized and stops compililing due to -Werror
>
> Known issues:
>
> - SLAB support not working
>
> - The cpsw network driver shows some issues.
>
> - ARM & PPC don't fall apart once booted. More testing doesn't
> hurt.
>
> - bcache with CONFIG_DEBUG_LOCK_ALLOC enabled does not compile.
...
On Thu, 15 Aug 2013 11:42:55 -0700
Fernando Lopez-Lezcano <[email protected]> wrote:
> On 08/12/2013 09:34 AM, Sebastian Andrzej Siewior wrote:
> > Dear RT folks!
> >
> > I'm pleased to announce the v3.10.6-rt3 patch set.
>
> I'm getting this when trying to build:
>
> drivers/md/bcache/request.c: In function 'cached_dev_write_complete':
> drivers/md/bcache/request.c:1008:2: error: implicit declaration of
> function 'up_read_non_owner' [-Werror=implicit-function-declaration]
> up_read_non_owner(&dc->writeback_lock);
> ^
> drivers/md/bcache/request.c: In function 'request_write':
> drivers/md/bcache/request.c:1034:2: error: implicit declaration of
> function 'down_read_non_owner' [-Werror=implicit-function-declaration]
> down_read_non_owner(&dc->writeback_lock);
> ^
> cc1: some warnings being treated as errors
>
Can you send us your config.
Thanks,
-- Steve
On 08/15/2013 12:22 PM, Steven Rostedt wrote:
> On Thu, 15 Aug 2013 11:42:55 -0700
> Fernando Lopez-Lezcano <[email protected]> wrote:
>
>> On 08/12/2013 09:34 AM, Sebastian Andrzej Siewior wrote:
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.10.6-rt3 patch set.
>>
>> I'm getting this when trying to build:
>>
>> drivers/md/bcache/request.c: In function 'cached_dev_write_complete':
>> drivers/md/bcache/request.c:1008:2: error: implicit declaration of
>> function 'up_read_non_owner' [-Werror=implicit-function-declaration]
>> up_read_non_owner(&dc->writeback_lock);
>> ^
>> drivers/md/bcache/request.c: In function 'request_write':
>> drivers/md/bcache/request.c:1034:2: error: implicit declaration of
>> function 'down_read_non_owner' [-Werror=implicit-function-declaration]
>> down_read_non_owner(&dc->writeback_lock);
>> ^
>> cc1: some warnings being treated as errors
>>
>
> Can you send us your config.
Attached...
-- Fernando
On 08/15/2013 09:22 PM, Steven Rostedt wrote:
> On Thu, 15 Aug 2013 11:42:55 -0700
> Fernando Lopez-Lezcano <[email protected]> wrote:
>
>> On 08/12/2013 09:34 AM, Sebastian Andrzej Siewior wrote:
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.10.6-rt3 patch set.
>>
>> I'm getting this when trying to build:
>>
>> drivers/md/bcache/request.c: In function 'cached_dev_write_complete':
>> drivers/md/bcache/request.c:1008:2: error: implicit declaration of
>> function 'up_read_non_owner' [-Werror=implicit-function-declaration]
>> up_read_non_owner(&dc->writeback_lock);
>> ^
>> drivers/md/bcache/request.c: In function 'request_write':
>> drivers/md/bcache/request.c:1034:2: error: implicit declaration of
>> function 'down_read_non_owner' [-Werror=implicit-function-declaration]
>> down_read_non_owner(&dc->writeback_lock);
>> ^
>> cc1: some warnings being treated as errors
>>
>
> Can you send us your config.
The problem is that bcache is using new semaphore functions which it
just introduced which rt does not know about. The comment above their
definition says that it is wrong to use them and completion is the
right way to do it.
So my question is, why don't we use completion but this nasty hack?
>
> Thanks,
>
> -- Steve
Sebastian
On 08/16/2013 12:01 AM, Sebastian Andrzej Siewior wrote:
> On 08/15/2013 09:22 PM, Steven Rostedt wrote:
>> On Thu, 15 Aug 2013 11:42:55 -0700
>> Fernando Lopez-Lezcano <[email protected]> wrote:
>>
>>> On 08/12/2013 09:34 AM, Sebastian Andrzej Siewior wrote:
>>>> Dear RT folks!
>>>>
>>>> I'm pleased to announce the v3.10.6-rt3 patch set.
>>>
>>> I'm getting this when trying to build:
>>>
>>> drivers/md/bcache/request.c: In function 'cached_dev_write_complete':
>>> drivers/md/bcache/request.c:1008:2: error: implicit declaration of
>>> function 'up_read_non_owner' [-Werror=implicit-function-declaration]
>>> up_read_non_owner(&dc->writeback_lock);
>>> ^
>>> drivers/md/bcache/request.c: In function 'request_write':
>>> drivers/md/bcache/request.c:1034:2: error: implicit declaration of
>>> function 'down_read_non_owner' [-Werror=implicit-function-declaration]
>>> down_read_non_owner(&dc->writeback_lock);
>>> ^
>>> cc1: some warnings being treated as errors
>>>
>>
>> Can you send us your config.
>
> The problem is that bcache is using new semaphore functions which it
> just introduced which rt does not know about. The comment above their
> definition says that it is wrong to use them and completion is the
> right way to do it.
> So my question is, why don't we use completion but this nasty hack?
In the meanwhile, any hope of a patch to be able to compile and test
with my current configuration?
Thanks,
-- Fernando
On Mon, 19 Aug 2013 10:23:44 -0700
Fernando Lopez-Lezcano <[email protected]> wrote:
> > The problem is that bcache is using new semaphore functions which it
> > just introduced which rt does not know about. The comment above their
> > definition says that it is wrong to use them and completion is the
> > right way to do it.
> > So my question is, why don't we use completion but this nasty hack?
I think I'm going to send them an email about that.
>
> In the meanwhile, any hope of a patch to be able to compile and test
> with my current configuration?
Can you boot without enabling CONFIG_BCACHE?
-- Steve
On 08/19/2013 05:29 PM, Steven Rostedt wrote:
> On Mon, 19 Aug 2013 10:23:44 -0700
> Fernando Lopez-Lezcano <[email protected]> wrote:
>
>
>>> The problem is that bcache is using new semaphore functions which it
>>> just introduced which rt does not know about. The comment above their
>>> definition says that it is wrong to use them and completion is the
>>> right way to do it.
>>> So my question is, why don't we use completion but this nasty hack?
>
> I think I'm going to send them an email about that.
>
>>
>> In the meanwhile, any hope of a patch to be able to compile and test
>> with my current configuration?
>
> Can you boot without enabling CONFIG_BCACHE?
I'm pretty sure I'll be able to do that. No real need in my personal
case AFAICT.
I'll try that next - it is just that I try very hard to keep the
configuration of my rt kernels as close as possible to the defaults that
Fedora uses (they get distributed as part of Planet CCRMA and there is
no telling what usage cases they will hit - it would be confusing to
have something that works on Fedora kernels and does not on equivalent
RT patched kernels).
Thanks for the heads up!,
-- Fernando
On Mon, 19 Aug 2013 20:29:03 -0400
Steven Rostedt <[email protected]> wrote:
> On Mon, 19 Aug 2013 10:23:44 -0700
> Fernando Lopez-Lezcano <[email protected]> wrote:
>
>
> > > The problem is that bcache is using new semaphore functions which it
> > > just introduced which rt does not know about. The comment above their
> > > definition says that it is wrong to use them and completion is the
> > > right way to do it.
> > > So my question is, why don't we use completion but this nasty hack?
>
> I think I'm going to send them an email about that.
>
Looking at it more, I can now see why they did what they did.
Grumble, we may need to bring back the old "compat" rwsem, or whatever
we called it, and just use that instead. And say that this code will
have no real time boosting.
-- Steve
On 08/20/2013 03:02 AM, Steven Rostedt wrote:
> Looking at it more, I can now see why they did what they did.
He is the only user in the whole kernel. It is somehow hard to believe
that it can't be solved differently.
> -- Steve
Sebastian
On Tue, 20 Aug 2013 09:14:15 +0200
Sebastian Andrzej Siewior <[email protected]> wrote:
> On 08/20/2013 03:02 AM, Steven Rostedt wrote:
> > Looking at it more, I can now see why they did what they did.
>
> He is the only user in the whole kernel. It is somehow hard to believe
> that it can't be solved differently.
>
Perhaps. But if I understand the code, this is what they have.
When a request is sent out, the writes must wait till it is complete
before it can do anything, thus the writers wait. When the request
finishes (by a different thread), it releases the reader, then the
writers can continue.
The problem is that the task that sends the request does not wait for
it to finish. But until the request does finish, all writers must wait.
To complicate the matter, it appears that more than one request can be
in transition at a time. That is, its not just a single request the a
writer must wait for, it could be many.
The only way I can think of at the moment to fix this without
non-owner, is to set up a wait queue, and a ref count. Basically have
this:
writer:
again:
down_write(lock);
if (refcount) {
up_write(lock);
wait_event(wq, !refcount);
goto again;
}
reader:
down_read(lock);
refcount++;
request();
up_read(lock);
completion:
down_read(lock);
refcount--;
up_read_(lock);
The refcount would need to be an atomic, but I think this would work.
Maybe I'll submit it to get rid of the one user of non_owner().
-- Steve
On 08/19/2013 05:29 PM, Steven Rostedt wrote:
> On Mon, 19 Aug 2013 10:23:44 -0700
> Fernando Lopez-Lezcano <[email protected]> wrote:
>
>>> The problem is that bcache is using new semaphore functions which it
>>> just introduced which rt does not know about. The comment above their
>>> definition says that it is wrong to use them and completion is the
>>> right way to do it.
>>> So my question is, why don't we use completion but this nasty hack?
>
> I think I'm going to send them an email about that.
>
>> In the meanwhile, any hope of a patch to be able to compile and test
>> with my current configuration?
>
> Can you boot without enabling CONFIG_BCACHE?
Just to confirm that the kernel builds, installs and boots fine without
this option...
-- Fernando
On Mon, 26 Aug 2013 01:12:02 +0530
Abhay Sachan <[email protected]> wrote:
> Hi All,
> I have installed 3.10.6 kernel on my HP laptop. I keep getting this message
> in dmesg after a few hours of usage. I was getting the similar messages in
> stable-3.9 too.
So this is with vanilla 3.10.6 and not the -rt version?
>
>
>
> [ 3274.234305] ------------[ cut here ]------------
> [ 3274.234332] WARNING: at kernel/workqueue.c:803
> wq_worker_waking_up+0x53/0x70()
> [ 3274.234335] Modules linked in: fuse autofs4 8021q garp stp llc
> cpufreq_ondemand ipv6 dm_mirror dm_region_hash dm_log dm_mod uinput ppdev
> parport_pc parport iTCO_wdt iTCO_vendor_support sg hp_wmi sparse_keymap
> btusb bluetooth tpm_infineon acpi_cpufreq freq_table mperf coretemp
> kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode arc4 iwldvm pcspkr
> mac80211 serio_raw intel_ips lpc_ich mfd_core iwlwifi cfg80211 rfkill
> snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
> snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc
> e1000e ptp pps_core wmi pata_pcmcia(F) ext4(F) jbd2(F) mbcache(F)
> yenta_socket(F) sdhci_pci(F) sdhci(F) mmc_core(F) firewire_ohci(F)
> firewire_core(F) crc_itu_t(F) sr_mod(F) cdrom(F) sd_mod(F) crc_t10dif(F)
> aesni_intel(F) ablk_helper(F) cryptd(F) lrw(F) gf128mul(F) glue_helper(F)
> aes_x86_64(F) ahci(F) libahci(F) i915(F) drm_kms_helper(F) drm(F)
> i2c_algo_bit(F) i2c_core(F) video(F)
> [ 3274.234474] CPU: 0 PID: 7 Comm: migration/0 Tainted: GF
> 3.10.6 #2
> [ 3274.234477] Hardware name: Hewlett-Packard HP EliteBook 8440p, BIOS
> 68CCU Ver. F.12 03/09/2011
> [ 3274.234489] ffffffff817caae0 ffff880133389bf8 ffffffff8153af15
> ffff880133389c38
> [ 3274.234495] ffffffff810414a0 ffff88013060c080 0000000000000003
> ffff880137cd2c80
> [ 3274.234500] ffff88013060c86c 0000000000000000 0000000000000092
> ffff880133389c48
> [ 3274.234505] Call Trace:
> [ 3274.234523] [<ffffffff8153af15>] dump_stack+0x19/0x1c
> [ 3274.234531] [<ffffffff810414a0>] warn_slowpath_common+0x70/0xa0
> [ 3274.234536] [<ffffffff810414ea>] warn_slowpath_null+0x1a/0x20
> [ 3274.234540] [<ffffffff8105e273>] wq_worker_waking_up+0x53/0x70
We've been trying to debug this for a while, but we are having trouble
triggering it. If you can download trace-cmd from:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
compile it and install it, and then run:
trace-cmd record -m 100000 -e all -l warn_slowpath_null:traceoff
And let it run till you see that warning again, and then I can set up a
place to send the trace.dat file that's created to me.
Thanks,
-- Steve
> [ 3274.234557] [<ffffffff8107498e>] ttwu_activate+0x3e/0x50
> [ 3274.234563] [<ffffffff8107559d>] ttwu_do_activate.clone.0+0x3d/0x60
> [ 3274.234567] [<ffffffff81078b46>] try_to_wake_up+0x216/0x2b0
> [ 3274.234572] [<ffffffff81078bf2>] default_wake_function+0x12/0x20
> [ 3274.234585] [<ffffffff81070229>] __wake_up_common+0x59/0x90
> [ 3274.234590] [<ffffffff810722d7>] complete+0x47/0x60
> [ 3274.234595] [<ffffffff81075240>] ? __migrate_task+0x150/0x150
> [ 3274.234604] [<ffffffff810bc240>] cpu_stopper_thread+0xd0/0x150
> [ 3274.234618] [<ffffffff8153c921>] ? __schedule+0x3d1/0x6d0
> [ 3274.234623] [<ffffffff8106f5ed>] smpboot_thread_fn+0xfd/0x180
> [ 3274.234627] [<ffffffff8106f4f0>] ? smpboot_create_threads+0x80/0x80
> [ 3274.234632] [<ffffffff8106749e>] kthread+0xce/0xe0
> [ 3274.234637] [<ffffffff810673d0>] ?
> kthread_freezable_should_stop+0x70/0x70
> [ 3274.234653] [<ffffffff81546c5c>] ret_from_fork+0x7c/0xb0
> [ 3274.234657] [<ffffffff810673d0>] ?
> kthread_freezable_should_stop+0x70/0x70
> [ 3274.234661] ---[ end trace fc26accd680695d5 ]---
> [ 3304.064987] Bridge firewalling registered
> [ 3317.239403] nr_pdflush_threads exported in /proc is scheduled for removal
> [ 3317.239550] sysctl: The scan_unevictable_pages sysctl/node-interface has
> been disabled for lack of a legitimate use case. If you have one, please
> send an email to [email protected].
>