* [Qemu-devel] [PATCH] Disable semaphores fallback code for OpenBSD
From: Brad Smith @ 2012-12-28 6:38 UTC (permalink / raw)
To: qemu-devel
Disable the semaphores fallback code for OpenBSD as modern OpenBSD
releases now have sem_timedwait().
Signed-off-by: Brad Smith <brad@comstyle.com>
diff --git a/include/qemu/thread-posix.h b/include/qemu/thread-posix.h
index 380bae2..0f30dcc 100644
--- a/include/qemu/thread-posix.h
+++ b/include/qemu/thread-posix.h
@@ -12,7 +12,7 @@ struct QemuCond {
};
struct QemuSemaphore {
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(__APPLE__) || defined(__NetBSD__)
pthread_mutex_t lock;
pthread_cond_t cond;
int count;
diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c
index 7be292e..6374df3 100644
--- a/qemu-thread-posix.c
+++ b/qemu-thread-posix.c
@@ -122,7 +122,7 @@ void qemu_sem_init(QemuSemaphore *sem, int init)
{
int rc;
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(__APPLE__) || defined(__NetBSD__)
rc = pthread_mutex_init(&sem->lock, NULL);
if (rc != 0) {
error_exit(rc, __func__);
@@ -147,7 +147,7 @@ void qemu_sem_destroy(QemuSemaphore *sem)
{
int rc;
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(__APPLE__) || defined(__NetBSD__)
rc = pthread_cond_destroy(&sem->cond);
if (rc < 0) {
error_exit(rc, __func__);
@@ -168,7 +168,7 @@ void qemu_sem_post(QemuSemaphore *sem)
{
int rc;
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(__APPLE__) || defined(__NetBSD__)
pthread_mutex_lock(&sem->lock);
if (sem->count == INT_MAX) {
rc = EINVAL;
@@ -206,7 +206,7 @@ int qemu_sem_timedwait(QemuSemaphore *sem, int ms)
int rc;
struct timespec ts;
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(__APPLE__) || defined(__NetBSD__)
compute_abs_deadline(&ts, ms);
pthread_mutex_lock(&sem->lock);
--sem->count;
@@ -248,7 +248,7 @@ int qemu_sem_timedwait(QemuSemaphore *sem, int ms)
void qemu_sem_wait(QemuSemaphore *sem)
{
-#if defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__)
+#if defined(__APPLE__) || defined(__NetBSD__)
pthread_mutex_lock(&sem->lock);
--sem->count;
while (sem->count < 0) {
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply related
* Re: hiawatha-8.6 using Yocto
From: GOPIKRISHNAN S @ 2012-12-28 6:30 UTC (permalink / raw)
To: Eric Bénard; +Cc: meta-freescale, yocto
In-Reply-To: <CAOkC3RZmx1ph=LKk2n9_oFAD=PjfbG6KCscQheAcRUigOuXiKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]
I am getting some errors while building hiawatha(using recipe from
openembedded). In investigation I found all return \type and parameter type
seems to be same & in all /usr/include/*.h files in declared as extern was
added before to make it visible in global. I wonder no problem was
not raised while compiling for my host platform (Debian 6 on x86), and
getting problem only doing it for my freescale board
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:39:5:
error: conflictin
g types for 'unsetenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:589:12:
note: previous declaration of 'unsetenv' was her
e
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:49:6:
error: conflictin
g types for 'clearenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:596:12:
note: previous declaration of 'clearenv' was her
e
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:39:5:
error: conflictin
g types for 'unsetenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:589:12:
note: previous declaration of 'unsetenv' was her
e
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:
In function 'strcasecm
p':/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:49:6:
error: conflic
ting types for 'clearenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:596:12:
note: previous declaration of 'clearenv' was her
e
On Thu, Dec 27, 2012 at 9:25 PM, GOPIKRISHNAN S <gopikrishnans@pec.edu>wrote:
> Thanks. Your link was so helpful.
>
>
> On Fri, Dec 21, 2012 at 10:53 PM, Eric Bénard <eric@eukrea.com> wrote:
>
>> Hi,
>>
>> Le Fri, 21 Dec 2012 21:41:38 +0530,
>> GOPIKRISHNAN S <gopikrishnans@pec.edu> a écrit :
>> > I was trying to install hiawatha on my freescale p2041rdb. But it is
>> using
>> > cmake to configure and install.
>> > How to write recipe for this with cmake. I have writted recipe for
>> packages
>> > with autotools, and make file.
>> > Any Idea???
>>
>> by using meta-openembedded/meta-webserver you can get hiawatha running
>> in a few minutes :
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-webserver/recipes-httpd/hiawatha
>>
>> Best regards
>> Eric
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3925 bytes --]
^ permalink raw reply
* Re: [meta-freescale] hiawatha-8.6 using Yocto
From: GOPIKRISHNAN S @ 2012-12-28 6:30 UTC (permalink / raw)
To: Eric Bénard; +Cc: meta-freescale, yocto
In-Reply-To: <CAOkC3RZmx1ph=LKk2n9_oFAD=PjfbG6KCscQheAcRUigOuXiKA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]
I am getting some errors while building hiawatha(using recipe from
openembedded). In investigation I found all return \type and parameter type
seems to be same & in all /usr/include/*.h files in declared as extern was
added before to make it visible in global. I wonder no problem was
not raised while compiling for my host platform (Debian 6 on x86), and
getting problem only doing it for my freescale board
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:39:5:
error: conflictin
g types for 'unsetenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:589:12:
note: previous declaration of 'unsetenv' was her
e
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:49:6:
error: conflictin
g types for 'clearenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:596:12:
note: previous declaration of 'clearenv' was her
e
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:39:5:
error: conflictin
g types for 'unsetenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:589:12:
note: previous declaration of 'unsetenv' was her
e
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:
In function 'strcasecm
p':/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/hiawatha-8.6-r2/hiawatha-8.6/src/alternative.c:49:6:
error: conflic
ting types for 'clearenv'
/media/sdk/3.1/QorIQ-SDK-V1.3-20121114-yocto/build_p2041rdb_release/tmp/sysroots/p2041rdb/usr/include/stdlib.h:596:12:
note: previous declaration of 'clearenv' was her
e
On Thu, Dec 27, 2012 at 9:25 PM, GOPIKRISHNAN S <gopikrishnans@pec.edu>wrote:
> Thanks. Your link was so helpful.
>
>
> On Fri, Dec 21, 2012 at 10:53 PM, Eric Bénard <eric@eukrea.com> wrote:
>
>> Hi,
>>
>> Le Fri, 21 Dec 2012 21:41:38 +0530,
>> GOPIKRISHNAN S <gopikrishnans@pec.edu> a écrit :
>> > I was trying to install hiawatha on my freescale p2041rdb. But it is
>> using
>> > cmake to configure and install.
>> > How to write recipe for this with cmake. I have writted recipe for
>> packages
>> > with autotools, and make file.
>> > Any Idea???
>>
>> by using meta-openembedded/meta-webserver you can get hiawatha running
>> in a few minutes :
>>
>> http://cgit.openembedded.org/meta-openembedded/tree/meta-webserver/recipes-httpd/hiawatha
>>
>> Best regards
>> Eric
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3925 bytes --]
^ permalink raw reply
* [PATCH net-next] bridge: respect RFC2863 operational state
From: Stephen Hemminger @ 2012-12-28 6:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The bridge link detection should follow the operational state
of the lower device, rather than the carrier bit. This allows devices
like tunnels that are controlled by userspace control plane to work
with bridge STP link management.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/bridge/br_if.c 2012-10-25 09:11:15.627272524 -0700
+++ b/net/bridge/br_if.c 2012-12-14 08:58:14.329847361 -0800
@@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
struct net_device *dev = p->dev;
struct net_bridge *br = p->br;
- if (netif_running(dev) && netif_carrier_ok(dev))
+ if (netif_running(dev) && netif_oper_up(dev))
p->path_cost = port_cost(dev);
if (!netif_running(br->dev))
return;
spin_lock_bh(&br->lock);
- if (netif_running(dev) && netif_carrier_ok(dev)) {
+ if (netif_running(dev) && netif_oper_up(dev))
if (p->state == BR_STATE_DISABLED)
br_stp_enable_port(p);
} else {
--- a/net/bridge/br_notify.c 2012-10-25 09:11:15.631272484 -0700
+++ b/net/bridge/br_notify.c 2012-12-14 08:57:36.954222724 -0800
@@ -82,7 +82,7 @@ static int br_device_event(struct notifi
break;
case NETDEV_UP:
- if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
+ if (netif_running(br->dev) && netif_oper_up(dev)) {
spin_lock_bh(&br->lock);
br_stp_enable_port(p);
spin_unlock_bh(&br->lock);
^ permalink raw reply
* [PATCH v2 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: Frank Li @ 2012-12-28 6:29 UTC (permalink / raw)
To: linux-arm-kernel
MX6 and mx28 support enhanced DMA descript buff to support 1588
ptp. But MX25, MX3x, MX5x can't support enhanced DMA descript buff.
Check fec type and choose correct DAM descript buff type.
Remove static config CONFIG_FEC_PTP.
ptp function will be auto detected.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
change from v1->v2:
1. remove CONFIG_FEC_PTP
2. fix code style issue. pass checkpatch
3. fix issue "return bdp++", return value is not added
4. remove unnecessary module parameter fec_ptp_enable
5. change get_nextdesc to fec_enet_get_nextdesc
drivers/net/ethernet/freescale/Kconfig | 9 +--
drivers/net/ethernet/freescale/Makefile | 3 +-
drivers/net/ethernet/freescale/fec.c | 175 +++++++++++++++++++------------
drivers/net/ethernet/freescale/fec.h | 16 +--
4 files changed, 116 insertions(+), 87 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index ec490d7..6048dc8 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -26,6 +26,7 @@ config FEC
ARCH_MXC || SOC_IMX28)
default ARCH_MXC || SOC_IMX28 if ARM
select PHYLIB
+ select PTP_1588_CLOCK
---help---
Say Y here if you want to use the built-in 10/100 Fast ethernet
controller on some Motorola ColdFire and Freescale i.MX processors.
@@ -92,12 +93,4 @@ config GIANFAR
This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
and MPC86xx family of chips, and the FEC on the 8540.
-config FEC_PTP
- bool "PTP Hardware Clock (PHC)"
- depends on FEC && ARCH_MXC && !SOC_IMX25 && !SOC_IMX27 && !SOC_IMX35 && !SOC_IMX5
- select PTP_1588_CLOCK
- --help---
- Say Y here if you want to use PTP Hardware Clock (PHC) in the
- driver. Only the basic clock operations have been implemented.
-
endif # NET_VENDOR_FREESCALE
diff --git a/drivers/net/ethernet/freescale/Makefile b/drivers/net/ethernet/freescale/Makefile
index d4d19b3..b7d58fe 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -2,8 +2,7 @@
# Makefile for the Freescale network device drivers.
#
-obj-$(CONFIG_FEC) += fec.o
-obj-$(CONFIG_FEC_PTP) += fec_ptp.o
+obj-$(CONFIG_FEC) += fec.o fec_ptp.o
obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx_phy.o
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 0704bca..290f91c 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -76,6 +76,8 @@
#define FEC_QUIRK_USE_GASKET (1 << 2)
/* Controller has GBIT support */
#define FEC_QUIRK_HAS_GBIT (1 << 3)
+/* Controller has extend desc buffer */
+#define FEC_QUICK_HAS_BUFDESC_EX (1 << 4)
static struct platform_device_id fec_devtype[] = {
{
@@ -93,7 +95,8 @@ static struct platform_device_id fec_devtype[] = {
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
}, {
.name = "imx6q-fec",
- .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT,
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUICK_HAS_BUFDESC_EX,
}, {
/* sentinel */
}
@@ -140,7 +143,7 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#endif
#endif /* CONFIG_M5272 */
-#if (((RX_RING_SIZE + TX_RING_SIZE) * 8) > PAGE_SIZE)
+#if (((RX_RING_SIZE + TX_RING_SIZE) * 32) > PAGE_SIZE)
#error "FEC: descriptor ring size constants too large"
#endif
@@ -192,6 +195,24 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
static int mii_cnt;
+static struct bufdesc *fec_enet_get_nextdesc(struct bufdesc *bdp, int is_ex)
+{
+ struct bufdesc_ex *ex = (struct bufdesc_ex *)bdp;
+ if (is_ex)
+ return (struct bufdesc *)(ex + 1);
+ else
+ return bdp + 1;
+}
+
+static struct bufdesc *fec_enet_get_prevdesc(struct bufdesc *bdp, int is_ex)
+{
+ struct bufdesc_ex *ex = (struct bufdesc_ex *)bdp;
+ if (is_ex)
+ return (struct bufdesc *)(ex - 1);
+ else
+ return bdp - 1;
+}
+
static void *swap_buffer(void *bufaddr, int len)
{
int i;
@@ -248,7 +269,11 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
*/
if (((unsigned long) bufaddr) & FEC_ALIGNMENT) {
unsigned int index;
- index = bdp - fep->tx_bd_base;
+ if (fep->bufdesc_ex)
+ index = (struct bufdesc_ex *)bdp -
+ (struct bufdesc_ex *)fep->tx_bd_base;
+ else
+ index = bdp - fep->tx_bd_base;
memcpy(fep->tx_bounce[index], skb->data, skb->len);
bufaddr = fep->tx_bounce[index];
}
@@ -280,17 +305,19 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
| BD_ENET_TX_LAST | BD_ENET_TX_TC);
bdp->cbd_sc = status;
-#ifdef CONFIG_FEC_PTP
- bdp->cbd_bdu = 0;
- if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&
+ if (fep->bufdesc_ex) {
+
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+ ebdp->cbd_bdu = 0;
+ if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&
fep->hwts_tx_en)) {
- bdp->cbd_esc = (BD_ENET_TX_TS | BD_ENET_TX_INT);
+ ebdp->cbd_esc = (BD_ENET_TX_TS | BD_ENET_TX_INT);
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
- } else {
+ } else {
- bdp->cbd_esc = BD_ENET_TX_INT;
+ ebdp->cbd_esc = BD_ENET_TX_INT;
+ }
}
-#endif
/* Trigger transmission start */
writel(0, fep->hwp + FEC_X_DES_ACTIVE);
@@ -298,7 +325,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (status & BD_ENET_TX_WRAP)
bdp = fep->tx_bd_base;
else
- bdp++;
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
if (bdp == fep->dirty_tx) {
fep->tx_full = 1;
@@ -359,8 +386,12 @@ fec_restart(struct net_device *ndev, int duplex)
/* Set receive and transmit descriptor base. */
writel(fep->bd_dma, fep->hwp + FEC_R_DES_START);
- writel((unsigned long)fep->bd_dma + sizeof(struct bufdesc) * RX_RING_SIZE,
- fep->hwp + FEC_X_DES_START);
+ if (fep->bufdesc_ex)
+ writel((unsigned long)fep->bd_dma + sizeof(struct bufdesc_ex)
+ * RX_RING_SIZE, fep->hwp + FEC_X_DES_START);
+ else
+ writel((unsigned long)fep->bd_dma + sizeof(struct bufdesc)
+ * RX_RING_SIZE, fep->hwp + FEC_X_DES_START);
fep->dirty_tx = fep->cur_tx = fep->tx_bd_base;
fep->cur_rx = fep->rx_bd_base;
@@ -448,17 +479,16 @@ fec_restart(struct net_device *ndev, int duplex)
writel(1 << 8, fep->hwp + FEC_X_WMRK);
}
-#ifdef CONFIG_FEC_PTP
- ecntl |= (1 << 4);
-#endif
+ if (fep->bufdesc_ex)
+ ecntl |= (1 << 4);
/* And last, enable the transmit and receive processing */
writel(ecntl, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
-#ifdef CONFIG_FEC_PTP
- fec_ptp_start_cyclecounter(ndev);
-#endif
+ if (fep->bufdesc_ex)
+ fec_ptp_start_cyclecounter(ndev);
+
/* Enable interrupts we wish to service */
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
}
@@ -544,19 +574,20 @@ fec_enet_tx(struct net_device *ndev)
ndev->stats.tx_packets++;
}
-#ifdef CONFIG_FEC_PTP
- if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS)) {
+ if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS) &&
+ fep->bufdesc_ex) {
struct skb_shared_hwtstamps shhwtstamps;
unsigned long flags;
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
spin_lock_irqsave(&fep->tmreg_lock, flags);
shhwtstamps.hwtstamp = ns_to_ktime(
- timecounter_cyc2time(&fep->tc, bdp->ts));
+ timecounter_cyc2time(&fep->tc, ebdp->ts));
spin_unlock_irqrestore(&fep->tmreg_lock, flags);
skb_tstamp_tx(skb, &shhwtstamps);
}
-#endif
+
if (status & BD_ENET_TX_READY)
printk("HEY! Enet xmit interrupt and TX_READY.\n");
@@ -575,7 +606,7 @@ fec_enet_tx(struct net_device *ndev)
if (status & BD_ENET_TX_WRAP)
bdp = fep->tx_bd_base;
else
- bdp++;
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
/* Since we have freed up a buffer, the ring is no longer full
*/
@@ -683,21 +714,23 @@ fec_enet_rx(struct net_device *ndev)
skb_put(skb, pkt_len - 4); /* Make room */
skb_copy_to_linear_data(skb, data, pkt_len - 4);
skb->protocol = eth_type_trans(skb, ndev);
-#ifdef CONFIG_FEC_PTP
+
/* Get receive timestamp from the skb */
- if (fep->hwts_rx_en) {
+ if (fep->hwts_rx_en && fep->bufdesc_ex) {
struct skb_shared_hwtstamps *shhwtstamps =
skb_hwtstamps(skb);
unsigned long flags;
+ struct bufdesc_ex *ebdp =
+ (struct bufdesc_ex *)bdp;
memset(shhwtstamps, 0, sizeof(*shhwtstamps));
spin_lock_irqsave(&fep->tmreg_lock, flags);
shhwtstamps->hwtstamp = ns_to_ktime(
- timecounter_cyc2time(&fep->tc, bdp->ts));
+ timecounter_cyc2time(&fep->tc, ebdp->ts));
spin_unlock_irqrestore(&fep->tmreg_lock, flags);
}
-#endif
+
if (!skb_defer_rx_timestamp(skb))
netif_rx(skb);
}
@@ -712,17 +745,19 @@ rx_processing_done:
status |= BD_ENET_RX_EMPTY;
bdp->cbd_sc = status;
-#ifdef CONFIG_FEC_PTP
- bdp->cbd_esc = BD_ENET_RX_INT;
- bdp->cbd_prot = 0;
- bdp->cbd_bdu = 0;
-#endif
+ if (fep->bufdesc_ex) {
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+
+ ebdp->cbd_esc = BD_ENET_RX_INT;
+ ebdp->cbd_prot = 0;
+ ebdp->cbd_bdu = 0;
+ }
/* Update BD pointer to next entry */
if (status & BD_ENET_RX_WRAP)
bdp = fep->rx_bd_base;
else
- bdp++;
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
/* Doing this here will keep the FEC running while we process
* incoming frames. On a heavily loaded network, we should be
* able to keep up at the expense of system resources.
@@ -1157,10 +1192,9 @@ static int fec_enet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
if (!phydev)
return -ENODEV;
-#ifdef CONFIG_FEC_PTP
- if (cmd == SIOCSHWTSTAMP)
+ if (cmd == SIOCSHWTSTAMP && fep->bufdesc_ex)
return fec_ptp_ioctl(ndev, rq, cmd);
-#endif
+
return phy_mii_ioctl(phydev, rq, cmd);
}
@@ -1180,7 +1214,7 @@ static void fec_enet_free_buffers(struct net_device *ndev)
FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
if (skb)
dev_kfree_skb(skb);
- bdp++;
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
}
bdp = fep->tx_bd_base;
@@ -1207,14 +1241,17 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, skb->data,
FEC_ENET_RX_FRSIZE, DMA_FROM_DEVICE);
bdp->cbd_sc = BD_ENET_RX_EMPTY;
-#ifdef CONFIG_FEC_PTP
- bdp->cbd_esc = BD_ENET_RX_INT;
-#endif
- bdp++;
+
+ if (fep->bufdesc_ex) {
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+ ebdp->cbd_esc = BD_ENET_RX_INT;
+ }
+
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
}
/* Set the last buffer to wrap. */
- bdp--;
+ bdp = fec_enet_get_prevdesc(bdp, fep->bufdesc_ex);
bdp->cbd_sc |= BD_SC_WRAP;
bdp = fep->tx_bd_base;
@@ -1224,14 +1261,16 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
bdp->cbd_sc = 0;
bdp->cbd_bufaddr = 0;
-#ifdef CONFIG_FEC_PTP
- bdp->cbd_esc = BD_ENET_RX_INT;
-#endif
- bdp++;
+ if (fep->bufdesc_ex) {
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+ ebdp->cbd_esc = BD_ENET_RX_INT;
+ }
+
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
}
/* Set the last buffer to wrap. */
- bdp--;
+ bdp = fec_enet_get_prevdesc(bdp, fep->bufdesc_ex);
bdp->cbd_sc |= BD_SC_WRAP;
return 0;
@@ -1444,7 +1483,11 @@ static int fec_enet_init(struct net_device *ndev)
/* Set receive and transmit descriptor base. */
fep->rx_bd_base = cbd_base;
- fep->tx_bd_base = cbd_base + RX_RING_SIZE;
+ if (fep->bufdesc_ex)
+ fep->tx_bd_base = (struct bufdesc *)
+ (((struct bufdesc_ex *)cbd_base) + RX_RING_SIZE);
+ else
+ fep->tx_bd_base = cbd_base + RX_RING_SIZE;
/* The FEC Ethernet specific entries in the device structure */
ndev->watchdog_timeo = TX_TIMEOUT;
@@ -1457,11 +1500,11 @@ static int fec_enet_init(struct net_device *ndev)
/* Initialize the BD for every fragment in the page. */
bdp->cbd_sc = 0;
- bdp++;
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
}
/* Set the last buffer to wrap */
- bdp--;
+ bdp = fec_enet_get_prevdesc(bdp, fep->bufdesc_ex);
bdp->cbd_sc |= BD_SC_WRAP;
/* ...and the same for transmit */
@@ -1471,11 +1514,11 @@ static int fec_enet_init(struct net_device *ndev)
/* Initialize the BD for every fragment in the page. */
bdp->cbd_sc = 0;
bdp->cbd_bufaddr = 0;
- bdp++;
+ bdp = fec_enet_get_nextdesc(bdp, fep->bufdesc_ex);
}
/* Set the last buffer to wrap */
- bdp--;
+ bdp = fec_enet_get_prevdesc(bdp, fep->bufdesc_ex);
bdp->cbd_sc |= BD_SC_WRAP;
fec_restart(ndev, 0);
@@ -1574,6 +1617,8 @@ fec_probe(struct platform_device *pdev)
fep->pdev = pdev;
fep->dev_id = dev_id++;
+ fep->bufdesc_ex = 0;
+
if (!fep->hwp) {
ret = -ENOMEM;
goto failed_ioremap;
@@ -1628,19 +1673,19 @@ fec_probe(struct platform_device *pdev)
goto failed_clk;
}
-#ifdef CONFIG_FEC_PTP
fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
+ fep->bufdesc_ex =
+ pdev->id_entry->driver_data & FEC_QUICK_HAS_BUFDESC_EX;
if (IS_ERR(fep->clk_ptp)) {
ret = PTR_ERR(fep->clk_ptp);
- goto failed_clk;
+ fep->bufdesc_ex = 0;
}
-#endif
clk_prepare_enable(fep->clk_ahb);
clk_prepare_enable(fep->clk_ipg);
-#ifdef CONFIG_FEC_PTP
- clk_prepare_enable(fep->clk_ptp);
-#endif
+ if (!IS_ERR(fep->clk_ptp))
+ clk_prepare_enable(fep->clk_ptp);
+
reg_phy = devm_regulator_get(&pdev->dev, "phy");
if (!IS_ERR(reg_phy)) {
ret = regulator_enable(reg_phy);
@@ -1668,9 +1713,8 @@ fec_probe(struct platform_device *pdev)
if (ret)
goto failed_register;
-#ifdef CONFIG_FEC_PTP
- fec_ptp_init(ndev, pdev);
-#endif
+ if (fep->bufdesc_ex)
+ fec_ptp_init(ndev, pdev);
return 0;
@@ -1681,9 +1725,8 @@ failed_init:
failed_regulator:
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_ipg);
-#ifdef CONFIG_FEC_PTP
- clk_disable_unprepare(fep->clk_ptp);
-#endif
+ if (!IS_ERR(fep->clk_ptp))
+ clk_disable_unprepare(fep->clk_ptp);
failed_pin:
failed_clk:
for (i = 0; i < FEC_IRQ_NUM; i++) {
@@ -1716,12 +1759,10 @@ fec_drv_remove(struct platform_device *pdev)
if (irq > 0)
free_irq(irq, ndev);
}
-#ifdef CONFIG_FEC_PTP
del_timer_sync(&fep->time_keep);
clk_disable_unprepare(fep->clk_ptp);
if (fep->ptp_clock)
ptp_clock_unregister(fep->ptp_clock);
-#endif
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_ipg);
iounmap(fep->hwp);
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index c5a3bc1..4862394 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -13,11 +13,9 @@
#define FEC_H
/****************************************************************************/
-#ifdef CONFIG_FEC_PTP
#include <linux/clocksource.h>
#include <linux/net_tstamp.h>
#include <linux/ptp_clock_kernel.h>
-#endif
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
defined(CONFIG_M520x) || defined(CONFIG_M532x) || \
@@ -94,14 +92,17 @@ struct bufdesc {
unsigned short cbd_datlen; /* Data length */
unsigned short cbd_sc; /* Control and status info */
unsigned long cbd_bufaddr; /* Buffer address */
-#ifdef CONFIG_FEC_PTP
+};
+
+struct bufdesc_ex {
+ struct bufdesc desc;
unsigned long cbd_esc;
unsigned long cbd_prot;
unsigned long cbd_bdu;
unsigned long ts;
unsigned short res0[4];
-#endif
};
+
#else
struct bufdesc {
unsigned short cbd_sc; /* Control and status info */
@@ -203,9 +204,7 @@ struct fec_enet_private {
struct clk *clk_ipg;
struct clk *clk_ahb;
-#ifdef CONFIG_FEC_PTP
struct clk *clk_ptp;
-#endif
/* The saved address of a sent-in-place packet/buffer, for skfree(). */
unsigned char *tx_bounce[TX_RING_SIZE];
@@ -243,8 +242,8 @@ struct fec_enet_private {
int full_duplex;
struct completion mdio_done;
int irq[FEC_IRQ_NUM];
+ int bufdesc_ex;
-#ifdef CONFIG_FEC_PTP
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_caps;
unsigned long last_overflow_check;
@@ -257,15 +256,12 @@ struct fec_enet_private {
int hwts_rx_en;
int hwts_tx_en;
struct timer_list time_keep;
-#endif
};
-#ifdef CONFIG_FEC_PTP
void fec_ptp_init(struct net_device *ndev, struct platform_device *pdev);
void fec_ptp_start_cyclecounter(struct net_device *ndev);
int fec_ptp_ioctl(struct net_device *ndev, struct ifreq *ifr, int cmd);
-#endif
/****************************************************************************/
#endif /* FEC_H */
--
1.7.1
^ permalink raw reply related
* Re: TUN problems (regression?)
From: Stephen Hemminger @ 2012-12-28 6:25 UTC (permalink / raw)
To: Jason Wang; +Cc: Eric Dumazet, Paul Moore, netdev
In-Reply-To: <50DD319A.5000708@redhat.com>
On Fri, 28 Dec 2012 13:43:54 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 12/28/2012 08:41 AM, Stephen Hemminger wrote:
> > On Fri, 21 Dec 2012 12:26:56 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> On 12/21/2012 11:39 AM, Eric Dumazet wrote:
> >>> On Fri, 2012-12-21 at 11:32 +0800, Jason Wang wrote:
> >>>> On 12/21/2012 07:50 AM, Stephen Hemminger wrote:
> >>>>> On Thu, 20 Dec 2012 15:38:17 -0800
> >>>>> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>>>>
> >>>>>> On Thu, 2012-12-20 at 18:16 -0500, Paul Moore wrote:
> >>>>>>> [CC'ing netdev in case this is a known problem I just missed ...]
> >>>>>>>
> >>>>>>> Hi Jason,
> >>>>>>>
> >>>>>>> I started doing some more testing with the multiqueue TUN changes and I ran
> >>>>>>> into a problem when running tunctl: running it once w/o arguments works as
> >>>>>>> expected, but running it a second time results in failure and a
> >>>>>>> kmem_cache_sanity_check() failure. The problem appears to be very repeatable
> >>>>>>> on my test VM and happens independent of the LSM/SELinux fixup patches.
> >>>>>>>
> >>>>>>> Have you seen this before?
> >>>>>>>
> >>>>>> Obviously code in tun_flow_init() is wrong...
> >>>>>>
> >>>>>> static int tun_flow_init(struct tun_struct *tun)
> >>>>>> {
> >>>>>> int i;
> >>>>>>
> >>>>>> tun->flow_cache = kmem_cache_create("tun_flow_cache",
> >>>>>> sizeof(struct tun_flow_entry), 0, 0,
> >>>>>> NULL);
> >>>>>> if (!tun->flow_cache)
> >>>>>> return -ENOMEM;
> >>>>>> ...
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> I have no idea why we would need a kmem_cache per tun_struct,
> >>>>>> and why we even need a kmem_cache.
> >>>>> Normally flow malloc/free should be good enough.
> >>>>> It might make sense to use private kmem_cache if doing hlist_nulls.
> >>>>>
> >>>>>
> >>>>> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
> >>>> Should be at least a global cache, I thought I can get some speed-up by
> >>>> using kmem_cache.
> >>>>
> >>>> Acked-by: Jason Wang <jasowang@redhat.com>
> >>> Was it with SLUB or SLAB ?
> >>>
> >>> Using generic kmalloc-64 is better than a dedicated kmem_cache of 48
> >>> bytes per object, as we guarantee each object is on a single cache line.
> >>>
> >>>
> >> Right, thanks for the explanation.
> >>
> > I wonder if TUN would be better if it used a array to translate
> > receive hash to receive queue. This is how real hardware works with the
> > indirection table, and it would allow RFS acceleration. The current flow
> > cache stuff is prone to DoS attack and scaling problems with lots of
> > short lived flows.
>
> The problem of indirection table is hash collision which may even happen
> when few flows existed.
Hash collision is fine, as long as the the statistical average of
hash across queue's is approximately equal it will be faster. A simple
array indirection is much faster than walking a hash table.
> For the RFS, we can open a API/ioctl for userspace to add or remove a
> flow cache.
RFS acceleration relies on programming the table. It is easier if
TUN looks more like hardware.
> For the DoS/scaling issue, I have an idea of:
> - limit the total number of flow entries in tun/tap
> - only update the flow entry every N (say 20 like ixgbe) packets or the
> the tcp packet has sync flag
> - I'm not sure skb_get_rxhash() is lightweight enough, or change to more
> lightweight one?
Ideally the hash should be programmable L2 vs L3, but that is splitting
hairs at this point.
Flow tables are scaling problem, especially on highly loaded servers where
they are most needed.
^ permalink raw reply
* Re: [PATCH 8/8] wildmatch: advance faster in <asterisk> + <literal> patterns
From: Junio C Hamano @ 2012-12-28 6:24 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1356163028-29967-9-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> compat, '*/*/*' on linux-2.6.git file list 2000 times, before:
> wildmatch 7s 985049us
> fnmatch 2s 735541us or 34.26% faster
>
> and after:
> wildmatch 4s 492549us
> fnmatch 0s 888263us or 19.77% slower
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> wildmatch.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/wildmatch.c b/wildmatch.c
> index 3794c4d..68b02e4 100644
> --- a/wildmatch.c
> +++ b/wildmatch.c
> @@ -132,6 +132,27 @@ static int dowild(const uchar *p, const uchar *text, unsigned int flags)
> while (1) {
> if (t_ch == '\0')
> break;
> + /*
> + * Try to advance faster when an asterisk is
> + * followed by a literal. We know in this case
> + * that the the string before the literal
> + * must belong to "*".
> + */
> + if (!is_glob_special(*p)) {
So far, we have looked at "*x" or "**x" in the pattern, p points at
'x' (not an asterisk), and we have "text" to match. For "text" to
match this pattern, the earlier part of it that is consumed to match
the asterisk must be followed by "x". "special" tells us if we are
allowed to treat '/' as matching the asterisk.
> + p_ch = *p;
> + if ((flags & WM_CASEFOLD) && ISUPPER(p_ch))
> + p_ch = tolower(p_ch);
That "x" in the example is picked up here and stored in "p_ch".
Let's skip over "text" and find that "x" in there.
> + while ((t_ch = *text) != '\0' &&
> + (!(flags & WM_PATHNAME) || t_ch != '/')) {
Why do we look at (flags & WM_PATHMAME) and not "special" here?
> + if ((flags & WM_CASEFOLD) && ISUPPER(t_ch))
> + t_ch = tolower(t_ch);
> + if (t_ch == p_ch)
> + break;
Found it.
> + text++;
> + }
> + if (t_ch != p_ch)
> + return WM_NOMATCH;
If we did not find that "x", then "**x" or "*x" can never match.
OK. And at this point "text" points at that "x" we found, and "p"
points at "x" after the asterisk in the pattern.
Looks good so far. Thanks.
> + }
> if ((matched = dowild(p, text, flags)) != WM_NOMATCH) {
> if (!special || matched != WM_ABORT_TO_STARSTAR)
> return matched;
^ permalink raw reply
* Re: [PATCH 4/8] wildmatch: support "no FNM_PATHNAME" mode
From: Junio C Hamano @ 2012-12-28 6:24 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1356163028-29967-5-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/wildmatch.c b/wildmatch.c
> index a79f97e..4fe1d65 100644
> --- a/wildmatch.c
> +++ b/wildmatch.c
> @@ -77,14 +77,17 @@ static int dowild(const uchar *p, const uchar *text, unsigned int flags)
> continue;
> case '?':
> /* Match anything but '/'. */
> - if (t_ch == '/')
> + if ((flags & WM_PATHNAME) && t_ch == '/')
> return WM_NOMATCH;
> continue;
> case '*':
> if (*++p == '*') {
> const uchar *prev_p = p - 2;
> while (*++p == '*') {}
> - if ((prev_p == text || *prev_p == '/') ||
> + if (!(flags & WM_PATHNAME))
> + /* without WM_PATHNAME, '*' == '**' */
> + special = 1;
> + else if ((prev_p == text || *prev_p == '/') ||
Not a new issue in this patch, but here, "prev_p" points into the
pattern string, two bytes before p, which is the byte before the
"**" that we are looking at (which might be before the beginning of
the pattern). "text" is the string we are trying to match that
pattern against. How can these two pointers be compared to yield a
meaningful value?
> (*p == '\0' || *p == '/' ||
> (p[0] == '\\' && p[1] == '/'))) {
OK. "**/", "**" (end of pattern), and "**\/" are handled here.
Do we have to worry about "**[/]" the same way, or a class never
matches the directory separator, even if it is a singleton class
that consists of '/' (which is fine by me)? If so, is "\/" more or
less like "[/]"?
^ permalink raw reply
* Bad magic number and
From: sham pavman @ 2012-12-28 6:18 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAD6i1fLn0L-v22cd1Ky2MAo7FhNYRiKL7+p1jYNMbxFwLe-YAQ@mail.gmail.com>
On Fri, Dec 28, 2012 at 11:44 AM, Prashant Shah <pshah.mumbai@gmail.com>wrote:
> Hi,
>
> On Fri, Dec 28, 2012 at 11:35 AM, sham pavman <shampavman.cg@gmail.com>
> wrote:
> > Here is the output
> >
> > # dumpe2fs -h /dev/sdb
> > dumpe2fs 1.42 (29-Nov-2011)
> > dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb
> > Couldn't find valid filesystem superblock.
>
> Try
>
> $partprobe
> $fdisk -l
>
No use..
# partprobe
root at Not-Specified:/home/z# fdisk -l
Disk /dev/sda: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders, total 117231408 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000539c8
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 78125055 39061504 83 Linux
/dev/sda2 78127102 82124799 1998849 5 Extended
/dev/sda5 78127104 82124799 1998848 82 Linux swap / Solaris
Disk /dev/sdb: 300.1 GB, 300101401088 bytes
255 heads, 63 sectors/track, 36485 cylinders, total 586135549 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000 <--------------------------------------- Does
this look fishy?
Disk /dev/sdb doesn't contain a valid partition table
>
> Regards
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121228/531021ce/attachment.html
^ permalink raw reply
* WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:7539
From: Linus Torvalds @ 2012-12-28 6:07 UTC (permalink / raw)
To: Brett Rudley, Arend van Spriel, Franky (Zhenhui) Lin,
Hante Meuleman, John W. Linville
Cc: Linux Wireless List, brcm80211-dev-list
Ok, maybe somebody is interested in this.. I don't know what triggered
it, but maybe the few lines around it give some clue.
I think it's new to 3.8-rc1, because I haven't seen it before (well,
I'm running current -git - v3.8.0-rc1-00035-g101e5c7470eb to be exact
- but the networking changes since -rc1 are small and seem unrelated).
But maybe it just happens under certain circumstances.
Linus
---
[ 573.596631] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp
filtering: enabled true, count 1 (implement)
[ 584.154535] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete:
Pkt tx suppressed, illegal channel possibly 1
[ 584.154628] brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete:
Pkt tx suppressed, illegal channel possibly 1
[ 584.925487] ------------[ cut here ]------------
[ 584.925521] WARNING: at
drivers/net/wireless/brcm80211/brcmsmac/main.c:7539
brcms_c_wait_for_tx_completion+0xa3/0xc0 [brcmsmac]()
[ 584.925525] Hardware name: MacBookAir4,1
[ 584.925527] Modules linked in: brcmsmac brcmutil bcma
[ 584.925541] Pid: 4312, comm: kworker/u:9 Not tainted
3.8.0-rc1-00035-g101e5c7470eb #4
[ 584.925544] Call Trace:
[ 584.925558] [<ffffffff8104308a>] warn_slowpath_common+0x7a/0xb0
[ 584.925565] [<ffffffff810430d5>] warn_slowpath_null+0x15/0x20
[ 584.925584] [<ffffffffa0024b03>]
brcms_c_wait_for_tx_completion+0xa3/0xc0 [brcmsmac]
[ 584.925597] [<ffffffffa00181b6>] brcms_ops_flush+0x36/0x50 [brcmsmac]
[ 584.925608] [<ffffffff81785b3d>] ieee80211_scan_work+0x18d/0x520
[ 584.925636] [<ffffffff8105bc19>] process_one_work+0x129/0x480
[ 584.925651] [<ffffffff8105c345>] worker_thread+0x155/0x3f0
[ 584.925674] [<ffffffff8106097b>] kthread+0xbb/0xc0
[ 584.925690] [<ffffffff817c68ec>] ret_from_fork+0x7c/0xb0
[ 584.925698] [<ffffffff810608c0>] ? kthread_freezable_should_stop+0x60/0x60
[ 584.925703] ---[ end trace eeea7613ef80ba9b ]---
[ 588.284074] brcmsmac bcma0:0: frameid != txh->TxFrameID
[ 588.284098] brcmsmac bcma0:0: MI_TFS: fatal
[ 588.284103] brcmsmac bcma0:0: wl0: fatal error, reinitializing
[ 588.286208] ieee80211 phy0: Hardware restart was requested
^ permalink raw reply
* Re: Which version of nilfs do you use?
From: Vyacheslav Dubeyko @ 2012-12-28 6:14 UTC (permalink / raw)
To: ARAI Shun-ichi; +Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121228.115843.568913897223506746.hermes-akuOmOme3sQYOdUovKs6ag@public.gmane.org>
On Fri, 2012-12-28 at 11:58 +0900, ARAI Shun-ichi wrote:
> In <BB9A0F28-A902-4FE4-BA58-A66EA93290F8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>;
> Elmer Zhang <freeboy6716-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote
> as Subject "Re: Which version of nilfs do you use?":
>
> > There is more than 2TB of data and a large number of databases, tables in our MySQL service. The conventional cold backup methods can not meet our needs. So we are trying to find some other methods.
>
> I posted report mail about the "bad btree node" error in 2012-11-30,
> I told about VirtualBox.
> When I met the error first, virtual disk file (approx. 16GB) was in
> NILFS FS.
>
> Zhang's DB is large. Perhaps there are files which has large size, I think.
> And these files are updated frequently.
>
> Can the common point (file size, update) cause inconsistency?
I think that it can be a synchronization issue. But it needs to
investigate the situation more deeply. As I can see, it is using 8 CPUs
in the case of the issue and it takes place frequent update. So, it can
be a ground for good issue reproducibility, from my point of view.
With the best regards,
Vyacheslav Dubeyko.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Bad magic number and
From: Prashant Shah @ 2012-12-28 6:14 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAD0Gp_YizTi=GYzyXgHcKWqvhgdGCo_ZH9j2-oaDRSFXSZHNYw@mail.gmail.com>
Hi,
On Fri, Dec 28, 2012 at 11:35 AM, sham pavman <shampavman.cg@gmail.com> wrote:
> Here is the output
>
> # dumpe2fs -h /dev/sdb
> dumpe2fs 1.42 (29-Nov-2011)
> dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb
> Couldn't find valid filesystem superblock.
Try
$partprobe
$fdisk -l
Regards
^ permalink raw reply
* Re: how to look for source code in kernel
From: Alex Belits @ 2012-12-28 5:37 UTC (permalink / raw)
To: anish singh
Cc: amit mehta, Henrique Rodrigues, kishore kumar,
Jonathan Neuschäfer, linux-kernel, Kernelnewbies
In-Reply-To: <CAK7N6vqw+DVSVaCXqiQBVa_d2o-rg-oA5t8+6WNaZ9Mb_iQqdw@mail.gmail.com>
On Fri, 28 Dec 2012, anish singh wrote:
>>> have source insight.We can use wine in linux but that sucks.
>> Funny you say that!
>> Never heard of cscope, ctags ?
> It is not as convenient as source insight or is it?
There is also LXR.
If it's not good enough for you, then don't look at it.
^ permalink raw reply
* RE: echo 1 > /proc/sys/vm/compact_memory -> sh: write error: Bad address
From: Liu Hui-R64343 @ 2012-12-28 6:07 UTC (permalink / raw)
To: David Rientjes; +Cc: Mel Gorman, linux-kernel@vger.kernel.org
In-Reply-To: <alpine.DEB.2.00.1212271435250.18214@chino.kir.corp.google.com>
>-----Original Message-----
>From: David Rientjes [mailto:rientjes@google.com]
>Sent: Friday, December 28, 2012 6:39 AM
>To: Liu Hui-R64343
>Cc: Mel Gorman; linux-kernel@vger.kernel.org
>Subject: Re: echo 1 > /proc/sys/vm/compact_memory -> sh: write error: Bad
>address
>
>On Thu, 27 Dec 2012, Liu Hui-R64343 wrote:
>
>> diff --git a/mm/compaction.c b/mm/compaction.c index c4bc5ac..d3cb27f
>> 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -732,8 +732,10 @@ int sysctl_compact_memory; int
>> sysctl_compaction_handler(struct ctl_table *table, int write,
>> void __user *buffer, size_t *length, loff_t
>> *ppos) {
>> - if (write)
>> - return compact_nodes();
>> + if (write) {
>> + compact_nodes();
>> + return *length;
>> + }
>>
>> return 0;
>> }
>
>No need to return the length at all, simply change compact_nodes() to return
>void, remove the return value, and do
>
> if (write)
> compact_nodes();
> return 0;
>
>and it should be fixed.
Yes, this works. Thanks,
> Could you write a changelog that shows the before
>and after behavior (not necessarily the implementation), sign-off the patch
>as described in Documentation/SubmittingPatches, running
>scripts/get_maintainer.pl on your new patch file, and sending it to all
>addresses that are listed?
OK, I will send out the patch as you suggested.
Happy holiday.
Jason Liu
^ permalink raw reply
* Re: Which version of nilfs do you use?
From: Vyacheslav Dubeyko @ 2012-12-28 6:06 UTC (permalink / raw)
To: Elmer Zhang
Cc: konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg,
linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <AAEC3976-3D79-4170-B1DC-2A04499392DE-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On Thu, 2012-12-27 at 17:47 +0800, Elmer Zhang wrote:
> Hi konishi ryusuke,
>
> I am trying to use NILFS2 to make MySQL cold backup, but the MySQL tables often be crashed. It seems there is some problems with nilfs filesystem.
>
As I remember, you reported initially the error message about issue with
(inode number=321775) and (blocknr=710153406). If you have new MySQL
tables' crashes then it means that you have new NILFS error messages in
your syslog. Do you have error messages about new inode numbers and
block numbers or about the same?
With the best regards,
Vyacheslav Dubeyko.
> I have described how I use nilfs in this mail: http://www.mail-archive.com/linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg01481.html
>
> Can I know which version of nilfs do you use, and what do you use nilfs for?
>
> Thanks,
> Elmer Zhang--
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Bad magic number and
From: sham pavman @ 2012-12-28 6:05 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAE0An6f5LkjoZU-F6OtNXVo_jWz3XWhS+Zk06vAKZH4aRYDApQ@mail.gmail.com>
Here is the output
# dumpe2fs -h /dev/sdb
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb
Couldn't find valid filesystem superblock.
On Fri, Dec 28, 2012 at 10:57 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:
>
>
> On Thu, Dec 27, 2012 at 8:29 PM, sham pavman <shampavman.cg@gmail.com>wrote:
>
>> I've tried that as well.. and the result is the same.
>> I've little idea on how to start debugging.
>> If you can provide some info it would be great.
>>
>
> What does dumpe2fs -h give ?
>
> Thanks -
> Manish
>
>
>
>>
>> Thanks
>>
>> On Fri, Dec 28, 2012 at 6:37 AM, Mulyadi Santosa <
>> mulyadi.santosa at gmail.com> wrote:
>>
>>> Hi...
>>>
>>> On Wed, Dec 26, 2012 at 12:19 PM, sham pavman <shampavman.cg@gmail.com>
>>> wrote:
>>> > <SNIP>
>>> > mkfs -t ext4 /dev/sdb
>>> > mke2fs 1.42 (29-Nov-2011)
>>>
>>> try using mkfs.ext4 instead....
>>>
>>> --
>>> regards,
>>>
>>> Mulyadi Santosa
>>> Freelance Linux trainer and consultant
>>>
>>> blog: the-hydra.blogspot.com
>>> training: mulyaditraining.blogspot.com
>>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
>
> --
> Thanks -
> Manish
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121228/5a1c1db1/attachment.html
^ permalink raw reply
* [Qemu-devel] [PATCH] Fix semaphores fallback code
From: Brad Smith @ 2012-12-28 6:00 UTC (permalink / raw)
To: qemu-devel
As reported in bug 1087114 the semaphores fallback code is broken which
results in QEMU crashing and making QEMU unusable.
This patch is from Paolo.
This needs to be back ported to the 1.3 stable tree as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Brad Smith <brad@comstyle.com>
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
index 7be292e..17f2d7c 100644
--- a/util/qemu-thread-posix.c
+++ b/util/qemu-thread-posix.c
@@ -213,6 +213,7 @@ int qemu_sem_timedwait(QemuSemaphore *sem, int ms)
while (sem->count < 0) {
rc = pthread_cond_timedwait(&sem->cond, &sem->lock, &ts);
if (rc == ETIMEDOUT) {
+ ++sem->count;
break;
}
if (rc != 0) {
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply related
* Re: [PATCH 01/19] netfilter: move nf_conntrack initialize out of pernet operations
From: Eric W. Biederman @ 2012-12-28 6:00 UTC (permalink / raw)
To: canqun zhang
Cc: Gao feng, netfilter-devel, netdev@vger.kernel.org,
Patrick McHardy, pablo
In-Reply-To: <CAFFEFTU8kxXV2pQ3B_goRs2Y7p2ecZ1YuSKSjfYF_58eD1tDqw@mail.gmail.com>
canqun zhang <canqunzhang@gmail.com> writes:
> yes，Network namespaces in general can be cleaned up in any order，but
> when doing /etc/ini.d/iptables restart, the system need cleaning up
> all net namespace,and init_net should be cleanup lastly.init_net is
> the first namespace,other net namespace is copied for it ,and it is
> diuty for Initializing resources,so It in itself is special.
"other net namespaces is copied for it" I don't have a clue what
you mean by that. Every network namespace starts out in a default
state not in a copied state.
Nowhere else in the network stack does &init_net have the duty
of initializing or cleaning up resources.
That /etc/init.d/iptables restart removes modules in general is a little
dubious. That /etc/init.d/iptables restart removes modules when there
are other existing network namespaces using those modules is down right
dangerous. Dangerous in the anyone can ssh into the machine way. I
suspect it has taken 5 years for this bug to show up because it is so
idiotic to remove code that someone else is using.
I won't argue that making it so that &init_net is the last network
namespace to go will solve this problem. But I can't see how adding
the guarantee that &init_net will always be cleaned up last is a good
long term solution.
Removing the init_net special case gives a simpler mental model, and
less to learn and maintain about network namespaces.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to look for source code in kernel
From: Chen Gang F T @ 2012-12-28 5:49 UTC (permalink / raw)
To: amit mehta
Cc: anish singh, Henrique Rodrigues, kishore kumar,
Jonathan Neuschäfer, linux-kernel
In-Reply-To: <CAOUxTKNgs4N-M5RR6YHyGeXQqRrg0_CJpxgT2OmN_buEP+jbjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
于 2012年12月28日 13:12, amit mehta 写道:
>>>> On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote:
>>>>> can anybody tell me how to look into source code, as most are hidden in
>>>>> kernel.
>>>> You can find the Linux source code at http://kernel.org/ .
>> for browsing the code unfortunately there is no good tool as in windows we
>> have source insight.We can use wine in linux but that sucks.
> Funny you say that!
> Never heard of cscope, ctags ?
at least for me:
vi (or vim) with another command line tools (grep, wc...) are enough.
for reading or editing source code: grasp one editor is enough.
I originally work under Windows OS,
using VC IDE and source insight for many years (at least 6 years).
but I never feel they are better than vi, and neither less than vi.
each editor has its own efficiency using ways,
what we need do is to grasp it.
when you grasp the editor (no matter what it is), it will be enough for you.
> -Amit
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Flying Transformer
[-- Attachment #2: chen_gang_flying_transformer.vcf --]
[-- Type: text/x-vcard, Size: 67 bytes --]
begin:vcard
fn:Chen Gang
n:;Chen Gang
version:2.1
end:vcard
^ permalink raw reply
* Re: how to look for source code in kernel
From: Chen Gang F T @ 2012-12-28 5:40 UTC (permalink / raw)
To: amit mehta
Cc: anish singh, Henrique Rodrigues, kishore kumar,
Jonathan Neuschäfer, linux-kernel, Kernelnewbies
In-Reply-To: <CAOUxTKNgs4N-M5RR6YHyGeXQqRrg0_CJpxgT2OmN_buEP+jbjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
于 2012年12月28日 13:12, amit mehta 写道:
>>>> On Thu, Dec 27, 2012 at 11:01:52PM +0530, kishore kumar wrote:
>>>>> can anybody tell me how to look into source code, as most are hidden in
>>>>> kernel.
>>>> You can find the Linux source code at http://kernel.org/ .
>> for browsing the code unfortunately there is no good tool as in windows we
>> have source insight.We can use wine in linux but that sucks.
> Funny you say that!
> Never heard of cscope, ctags ?
at least for me:
vi (or vim) with another command line tools (grep, wc...) are enough.
for reading or editing source code: grasp one editor is enough.
I originally work under Windows OS
using VC IDE and source insight for many years (at least 6 years).
but I never feel they are better than vi, and neither less than vi.
each editor has its own efficiency using ways,
what we need do is to grasp it.
when you grasp the editor (no matter what it is), it will be enough for you.
>
> -Amit
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Flying Transformer
[-- Attachment #2: chen_gang_flying_transformer.vcf --]
[-- Type: text/x-vcard, Size: 67 bytes --]
begin:vcard
fn:Chen Gang
n:;Chen Gang
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] video: drm: exynos: mie bypass enable for fimd
From: Inki Dae @ 2012-12-28 5:47 UTC (permalink / raw)
To: Leela Krishna Amudala; +Cc: linux-samsung-soc, kgene.kim, dri-devel
In-Reply-To: <CAL1wa8d+cwkL5uWyYv9Kx_Cdhm_MTrL2hc7z4QX+vgDTtzMpKw@mail.gmail.com>
2012/12/28 Leela Krishna Amudala <l.krishna@samsung.com>:
> Hello Inki Dae,
>
> On Thu, Dec 27, 2012 at 11:47 AM, Inki Dae <inki.dae@samsung.com> wrote:
>>
>> Hi,
>>
>> DISP1BLK_CFG register is related to GScaler, HDCP and MIXER as well. So
>> it's not good that this register is controlled in fimd module. And I think
>> the function to control the register should be placed in SoC common file .
>> In other words, other drivers should be able to control the register through
>> common thing also.
>>
>
> Thanks for reviewing the patch.
> You mean to say that this functionality should be implemented at arch side
> and called by drivers using call back functions ?
>
> If so, then if we moved the driver to full DT version, all the call
> backs will be removed.
> Then how to make a call to this function?
>
> So I thought other drivers (apart from Fimd) also parses the
> appropriate nodes and
> program the register as per the need.
>
> Please correct me if my understanding is wrong.
>
The base address of DISP1BLK_CFG already was iorempped by
iotable_init() at machine init. So you can control DISP1BLK_CFG
register using only offset. But your patch does ioremap again and also
even not iounmap. This is ugly. Please see
arch/arm/plat-samsung/setup-mipiphy.c how the common register is
controlled and this is a good example. And please abuse dt.
> Best Wishes,
> Leela Krishna Amudala.
>
>
>> Thanks,
>> Inki Dae
>>
>> 2012/12/26 Leela Krishna Amudala <l.krishna@samsung.com>
>>>
>>> Bypasses the mie for fimd by parsing the register and bit offset values
>>> from "mie-bypass" node, if "mie-bypass" node is present in the dts file.
>>>
>>> Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 55
>>> ++++++++++++++++++++++++++++++++
>>> 1 file changed, 55 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index bf0d9ba..f8ad259 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -118,6 +118,12 @@ static const struct of_device_id
>>> fimd_driver_dt_match[] = {
>>> MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
>>> #endif
>>>
>>> +struct mie_bypass {
>>> + u32 enable_bypass;
>>> + void __iomem *bypass_reg;
>>> + u32 bypass_bit_offset;
>>> +};
>>> +
>>> static inline struct fimd_driver_data *drm_fimd_get_driver_data(
>>> struct platform_device *pdev)
>>> {
>>> @@ -133,6 +139,41 @@ static inline struct fimd_driver_data
>>> *drm_fimd_get_driver_data(
>>> platform_get_device_id(pdev)->driver_data;
>>> }
>>>
>>> +static struct mie_bypass *parse_mie_bypass_for_fimd(struct device *dev,
>>> + struct device_node
>>> *mie_bypass_node)
>>> +{
>>> + struct mie_bypass *bypass_data;
>>> + u32 phy_address;
>>> +
>>> + bypass_data = devm_kzalloc(dev, sizeof(*bypass_data),
>>> GFP_KERNEL);
>>> + if (!bypass_data) {
>>> + dev_err(dev, "memory allocation for bypass data
>>> failed\n");
>>> + return ERR_PTR(-ENOMEM);
>>> + }
>>> + of_property_read_u32(mie_bypass_node,
>>> "samsung,mie-bypass-enable",
>>> + &bypass_data->enable_bypass);
>>> + of_property_read_u32(mie_bypass_node, "samsung,disp1blk-cfg-reg",
>>> + &phy_address);
>>> + of_property_read_u32(mie_bypass_node,
>>> "samsung,bypass-bit-offset",
>>> + &bypass_data->bypass_bit_offset);
>>> +
>>> + bypass_data->bypass_reg = ioremap(phy_address, SZ_4);
>>>
>>> + if (!bypass_data->bypass_reg) {
>>> + dev_err(dev, "failed to ioremap phy_address\n");
>>> + return ERR_PTR(-ENOMEM);
>>> + }
>>> + return bypass_data;
>>> +}
>>>
>>> +
>>> +static void mie_bypass_for_fimd(struct mie_bypass *bypass_data)
>>> +{
>>> + u32 reg;
>>> +
>>> + reg = __raw_readl(bypass_data->bypass_reg);
>>> + reg |= (1 << bypass_data->bypass_bit_offset);
>>> + __raw_writel(reg, bypass_data->bypass_reg);
>>> +}
>>> +
>>> static bool fimd_display_is_connected(struct device *dev)
>>> {
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> @@ -906,12 +947,26 @@ static int __devinit fimd_probe(struct
>>> platform_device *pdev)
>>> struct exynos_drm_fimd_pdata *pdata;
>>> struct exynos_drm_panel_info *panel;
>>> struct resource *res;
>>> + struct device_node *mie_bypass_node;
>>> + struct mie_bypass *bypass_data = NULL;
>>> int win;
>>> int ret = -EINVAL;
>>>
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>>
>>> pdata = pdev->dev.platform_data;
>>> + if (pdev->dev.of_node) {
>>> + mie_bypass_node = of_find_node_by_name(pdev->dev.of_node,
>>> + "mie-bypass");
>>> + if (mie_bypass_node) {
>>> + bypass_data =
>>> parse_mie_bypass_for_fimd(&pdev->dev,
>>> + mie_bypass_node);
>>>
>>> + if (IS_ERR(bypass_data))
>>> + return PTR_ERR(bypass_data);
>>> + if (bypass_data->enable_bypass)
>>> + mie_bypass_for_fimd(bypass_data);
>>> + }
>>> + }
>>> if (!pdata) {
>>> dev_err(dev, "no platform data specified\n");
>>> return -EINVAL;
>>> --
>>> 1.8.0
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: TUN problems (regression?)
From: Jason Wang @ 2012-12-28 5:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, Paul Moore, netdev
In-Reply-To: <20121227164106.078604a8@nehalam.linuxnetplumber.net>
On 12/28/2012 08:41 AM, Stephen Hemminger wrote:
> On Fri, 21 Dec 2012 12:26:56 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> On 12/21/2012 11:39 AM, Eric Dumazet wrote:
>>> On Fri, 2012-12-21 at 11:32 +0800, Jason Wang wrote:
>>>> On 12/21/2012 07:50 AM, Stephen Hemminger wrote:
>>>>> On Thu, 20 Dec 2012 15:38:17 -0800
>>>>> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>>
>>>>>> On Thu, 2012-12-20 at 18:16 -0500, Paul Moore wrote:
>>>>>>> [CC'ing netdev in case this is a known problem I just missed ...]
>>>>>>>
>>>>>>> Hi Jason,
>>>>>>>
>>>>>>> I started doing some more testing with the multiqueue TUN changes and I ran
>>>>>>> into a problem when running tunctl: running it once w/o arguments works as
>>>>>>> expected, but running it a second time results in failure and a
>>>>>>> kmem_cache_sanity_check() failure. The problem appears to be very repeatable
>>>>>>> on my test VM and happens independent of the LSM/SELinux fixup patches.
>>>>>>>
>>>>>>> Have you seen this before?
>>>>>>>
>>>>>> Obviously code in tun_flow_init() is wrong...
>>>>>>
>>>>>> static int tun_flow_init(struct tun_struct *tun)
>>>>>> {
>>>>>> int i;
>>>>>>
>>>>>> tun->flow_cache = kmem_cache_create("tun_flow_cache",
>>>>>> sizeof(struct tun_flow_entry), 0, 0,
>>>>>> NULL);
>>>>>> if (!tun->flow_cache)
>>>>>> return -ENOMEM;
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>>
>>>>>> I have no idea why we would need a kmem_cache per tun_struct,
>>>>>> and why we even need a kmem_cache.
>>>>> Normally flow malloc/free should be good enough.
>>>>> It might make sense to use private kmem_cache if doing hlist_nulls.
>>>>>
>>>>>
>>>>> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>>>> Should be at least a global cache, I thought I can get some speed-up by
>>>> using kmem_cache.
>>>>
>>>> Acked-by: Jason Wang <jasowang@redhat.com>
>>> Was it with SLUB or SLAB ?
>>>
>>> Using generic kmalloc-64 is better than a dedicated kmem_cache of 48
>>> bytes per object, as we guarantee each object is on a single cache line.
>>>
>>>
>> Right, thanks for the explanation.
>>
> I wonder if TUN would be better if it used a array to translate
> receive hash to receive queue. This is how real hardware works with the
> indirection table, and it would allow RFS acceleration. The current flow
> cache stuff is prone to DoS attack and scaling problems with lots of
> short lived flows.
The problem of indirection table is hash collision which may even happen
when few flows existed.
For the RFS, we can open a API/ioctl for userspace to add or remove a
flow cache.
For the DoS/scaling issue, I have an idea of:
- limit the total number of flow entries in tun/tap
- only update the flow entry every N (say 20 like ixgbe) packets or the
the tcp packet has sync flag
- I'm not sure skb_get_rxhash() is lightweight enough, or change to more
lightweight one?
Any suggestions?
Thanks
^ permalink raw reply
* [Qemu-devel] [PATCH 2/3 v2] Reset qemu timers when guest reset
From: Bharat Bhushan @ 2012-12-28 5:16 UTC (permalink / raw)
To: qemu-devel, qemu-ppc, agraf; +Cc: Bharat Bhushan
In-Reply-To: <1356671812-7634-1-git-send-email-bharat.bhushan@freescale.com>
This patch install the timer reset handler. This will be called when
the guest is reset.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v2: same as v1
hw/ppc_booke.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/hw/ppc_booke.c b/hw/ppc_booke.c
index d51e7fa..837a5b6 100644
--- a/hw/ppc_booke.c
+++ b/hw/ppc_booke.c
@@ -231,6 +231,16 @@ void store_booke_tcr(CPUPPCState *env, target_ulong val)
}
+static void ppc_booke_timer_reset_handle(void *opaque)
+{
+ CPUPPCState *env = opaque;
+
+ env->spr[SPR_BOOKE_TSR] = 0;
+ env->spr[SPR_BOOKE_TCR] = 0;
+
+ booke_update_irq(env);
+}
+
void ppc_booke_timers_init(CPUPPCState *env, uint32_t freq, uint32_t flags)
{
ppc_tb_t *tb_env;
@@ -251,4 +261,6 @@ void ppc_booke_timers_init(CPUPPCState *env, uint32_t freq, uint32_t flags)
qemu_new_timer_ns(vm_clock, &booke_fit_cb, env);
booke_timer->wdt_timer =
qemu_new_timer_ns(vm_clock, &booke_wdt_cb, env);
+
+ qemu_register_reset(ppc_booke_timer_reset_handle, env);
}
--
1.7.0.4
^ permalink raw reply related
* Re: Bad magic number and
From: Prashant Shah @ 2012-12-28 5:38 UTC (permalink / raw)
To: Manish Katiyar; +Cc: sham pavman, Mulyadi Santosa, linux-kernel, kernelnewbies
In-Reply-To: <CAE0An6f5LkjoZU-F6OtNXVo_jWz3XWhS+Zk06vAKZH4aRYDApQ@mail.gmail.com>
Hi,
On Fri, Dec 28, 2012 at 10:57 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:
>
>
> On Thu, Dec 27, 2012 at 8:29 PM, sham pavman <shampavman.cg@gmail.com>
> wrote:
>>
>> I've tried that as well.. and the result is the same.
>> I've little idea on how to start debugging.
>> If you can provide some info it would be great.
Check your mkfs and mount commands. You have specified the whole disk
instead of partition. It should be...
mkfs -t ext4 /dev/sdb1
mount -t ext4 /dev/sdb1 /mnt/test
Regards.
^ permalink raw reply
* Bad magic number and
From: Prashant Shah @ 2012-12-28 5:38 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAE0An6f5LkjoZU-F6OtNXVo_jWz3XWhS+Zk06vAKZH4aRYDApQ@mail.gmail.com>
Hi,
On Fri, Dec 28, 2012 at 10:57 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:
>
>
> On Thu, Dec 27, 2012 at 8:29 PM, sham pavman <shampavman.cg@gmail.com>
> wrote:
>>
>> I've tried that as well.. and the result is the same.
>> I've little idea on how to start debugging.
>> If you can provide some info it would be great.
Check your mkfs and mount commands. You have specified the whole disk
instead of partition. It should be...
mkfs -t ext4 /dev/sdb1
mount -t ext4 /dev/sdb1 /mnt/test
Regards.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.