* [PATCH] imx: add polled io uart methods
From: Dirk Behme @ 2011-12-01 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111019035249.GA20598@lithium.compnerd.org>
On 19.10.2011 05:52, Saleem Abdulrasool wrote:
> On Tue, 18 Oct 2011, Uwe Kleine-K?nig wrote:
>
>> On Sun, Oct 16, 2011 at 08:22:01PM -0700, Saleem Abdulrasool wrote:
>>> These methods are invoked if the iMX uart is used in conjuction with kgdb during
>>> early boot. In order to access the UART without the interrupts, the kernel uses
>>> the basic polling methods for IO with the device. With these methods
>>> implemented, it is now possible to enable kgdb during early boot over serial.
>>>
>>> Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
>>> ---
>>> drivers/tty/serial/imx.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 77 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>>> index 7e91b3d..4fcf9ca 100644
>>> --- a/drivers/tty/serial/imx.c
>>> +++ b/drivers/tty/serial/imx.c
>>> @@ -102,6 +102,7 @@
>>> #define UCR2_STPB (1<<6) /* Stop */
>>> #define UCR2_WS (1<<5) /* Word size */
>>> #define UCR2_RTSEN (1<<4) /* Request to send interrupt enable */
>>> +#define UCR2_ATEN (1<<3) /* Aging Timer Enable */
>>> #define UCR2_TXEN (1<<2) /* Transmitter enabled */
>>> #define UCR2_RXEN (1<<1) /* Receiver enabled */
>>> #define UCR2_SRST (1<<0) /* SW reset */
>>> @@ -1075,6 +1076,77 @@ imx_verify_port(struct uart_port *port, struct serial_struct *ser)
>>> return ret;
>>> }
>>>
>>> +
>> needless newline
>
> Removed.
>
>>> +#if defined(CONFIG_CONSOLE_POLL)
>>> +static int imx_poll_get_char(struct uart_port *port)
>>> +{
>>> + volatile unsigned int status;
>> Why is that volatile?
>
> It shouldnt be, removed the volatile attribute. Im not sure why that was there,
> it really doesnt make any sense since there isnt any inline assembler there to
> confuse the compiler.
>
>>> + unsigned int cr1, cr2, cr3;
>>> + unsigned char c;
>>> +
>>> + /* save control registers */
>>> + cr1 = readl(port->membase + UCR1);
>>> + cr2 = readl(port->membase + UCR2);
>>> + cr3 = readl(port->membase + UCR3);
>>> +
>> Best regards
>> Uwe
>
> Thanks for the review. Ive not attached the updated patch since Id like to make
> the changes that Sascha suggested, and I shall post the updated patch
> subsequently.
Any update on this?
Many thanks
Dirk
^ permalink raw reply
* [PATCH V3] mmc: Kill block requests if card is removed
From: Sujit Reddy Thumma @ 2011-12-01 10:30 UTC (permalink / raw)
To: adrian.hunter; +Cc: per.lkml, linux-mmc, linux-arm-msm, Sujit Reddy Thumma, cjb
Kill block requests when the host realizes that the card is
removed from the slot and is sure that subsequent requests
are bound to fail. Do this silently so that the block
layer doesn't output unnecessary error messages.
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
---
Changes in v3:
- Dropped dependency on Per's patch and is now dependent
on "[PATCH V4] mmc: allow upper layers to determine immediately
if a card has been removed" by Adrian Hunter.
- Modified commit text slightly as Adrian has
implemented his own suggestion in a different patch.
Changes in v2:
- Changed the implementation with further comments from Adrian
- Set the card removed flag in bus notifier callbacks
- This patch is now dependent on patch from Per Forlin:
http://thread.gmane.org/gmane.linux.kernel.mmc/11128/focus=11211
---
drivers/mmc/card/block.c | 14 +++++++++++++-
drivers/mmc/card/queue.c | 5 +++++
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c80bb6d..20350cb 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -119,6 +119,7 @@ enum mmc_blk_status {
MMC_BLK_ABORT,
MMC_BLK_DATA_ERR,
MMC_BLK_ECC_ERR,
+ MMC_BLK_NOMEDIUM,
};
module_param(perdev_minors, int, 0444);
@@ -565,6 +566,7 @@ static int get_card_status(struct mmc_card *card, u32 *status, int retries)
return err;
}
+#define ERR_NOMEDIUM 3
#define ERR_RETRY 2
#define ERR_ABORT 1
#define ERR_CONTINUE 0
@@ -648,8 +650,12 @@ static int mmc_blk_cmd_recovery(struct mmc_card *card, struct request *req,
}
/* We couldn't get a response from the card. Give up. */
- if (err)
+ if (err) {
+ /* Check if the card is removed */
+ if (mmc_detect_card_removed(card->host))
+ return ERR_NOMEDIUM;
return ERR_ABORT;
+ }
/* Flag ECC errors */
if ((status & R1_CARD_ECC_FAILED) ||
@@ -922,6 +928,8 @@ static int mmc_blk_err_check(struct mmc_card *card,
return MMC_BLK_RETRY;
case ERR_ABORT:
return MMC_BLK_ABORT;
+ case ERR_NOMEDIUM:
+ return MMC_BLK_NOMEDIUM;
case ERR_CONTINUE:
break;
}
@@ -1255,6 +1263,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
if (!ret)
goto start_new_req;
break;
+ case MMC_BLK_NOMEDIUM:
+ goto cmd_abort;
}
if (ret) {
@@ -1271,6 +1281,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
cmd_abort:
spin_lock_irq(&md->lock);
+ if (mmc_card_removed(card))
+ req->cmd_flags |= REQ_QUIET;
while (ret)
ret = __blk_end_request(req, -EIO, blk_rq_cur_bytes(req));
spin_unlock_irq(&md->lock);
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index dcad59c..2517547 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -29,6 +29,8 @@
*/
static int mmc_prep_request(struct request_queue *q, struct request *req)
{
+ struct mmc_queue *mq = q->queuedata;
+
/*
* We only like normal block requests and discards.
*/
@@ -37,6 +39,9 @@ static int mmc_prep_request(struct request_queue *q, struct request *req)
return BLKPREP_KILL;
}
+ if (mq && mmc_card_removed(mq->card))
+ return BLKPREP_KILL;
+
req->cmd_flags |= REQ_DONTPREP;
return BLKPREP_OK;
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH] ARM: S3C64XX: Add linux/export.h to dev-spi.c
From: Kukjin Kim @ 2011-12-01 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1322490819-18971-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> This is required for the EXPORT_SYMBOL()s the code uses, previously the
> header was being included implicitly by another header.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> arch/arm/mach-s3c64xx/dev-spi.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/dev-spi.c b/arch/arm/mach-s3c64xx/dev-
> spi.c
> index 86fb130..3f437e7 100644
> --- a/arch/arm/mach-s3c64xx/dev-spi.c
> +++ b/arch/arm/mach-s3c64xx/dev-spi.c
> @@ -10,6 +10,7 @@
>
> #include <linux/kernel.h>
> #include <linux/string.h>
> +#include <linux/export.h>
> #include <linux/platform_device.h>
> #include <linux/dma-mapping.h>
> #include <linux/gpio.h>
> --
> 1.7.7.3
Right, will apply for v3.2.
But since Padmavathi's SPI consolidation patches removes dev-spi.c files so
this can be dropped for v3.3, and as a note, I will look at other patches
tomorrow :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [Qemu-devel] Boot from disk problem
From: Artyom Tarasenko @ 2011-12-01 10:29 UTC (permalink / raw)
To: Blue Swirl, Ignacio Geli; +Cc: Andreas Färber, qemu-devel
In-Reply-To: <CAAu8pHscQ9LEkjMF66PKAgyW8NZAbHJL=HmcjZW0DA0243XSHg@mail.gmail.com>
On Sat, Nov 26, 2011 at 9:01 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Fri, Nov 25, 2011 at 18:24, Ignacio Geli <igeli@itecnis.com> wrote:
>>
>> El 25/11/11 13:01, Andreas Färber escribió:
>>
>> Hi,
>>
>> Am 25.11.2011 16:23, schrieb Ignacio Geli:
>>
>> Im trying to run a solaris 2.5.1 vm acording the instructions of i found
>> in this blog:
>> http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html#uds-search-results
>
> I'm not sure if Artyom has submitted all his patches to QEMU yet.
This stuff is in. Definitely worked at 0.13 - 0.14 times, but I never
had time to check 0.15+.
>> compile my qemu with:
>> git clone git://git.savannah.nongnu.org/qemu.git
>> cd qemu
>> ./configure --target-list=sparc-softmmu
>> make
>> (version 0.13.50)
>>
>> That 2009 blog is outdated: QEMU now lives in
>> git://git.qemu.org/qemu.git
>> and should be at 0.15.93 (1.0-rc3). Compare http://qemu.org for details.
>>
>> CC'ed sparc maintainer and Artyom.
>>
>> Andreas
>>
>> Andesas tks for the info.
>> upgrading to 0.15.1 did not solve the issue.
>>
>> Adding some info:
>>
>> QEMU emulator version 0.15.1, Copyright (c) 2003-2008 Fabrice Bellard
>> Linux ws2132 2.6.32-5-openvz-amd64 #1 SMP Mon Oct 3 05:12:50 UTC 2011 x86_64 GNU/Linux
>> Debian squeeze
>>
>>
>> Regards!
>>
>> Ive downloaded the ss5.bin bios (sparc station 5)) I have the solaris
>> disk and i can do the installation but can't get the disk to boot.
>>
>> I can boot from the cd, mount and check the /etc/system file it has the
>> "set scsi_options=0x58" option i set to make it work, still not working:
>>
>> Here is the output:
>>
>> /ok boot disk0:d
>> Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@0,0:d File
>> and args:
>> SunOS Release 5.5.1 Version Generic [UNIX(R) System V Release 4.0]
>> Copyright (c) 1983-1996, Sun Microsystems, Inc.
>> WARNING:
>> /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@1,0
>> (sd1):
>> corrupt label - bad geometry
>>
>> Label says 1310720 blocks, Drive says 883120 blocks
>> Cannot mount root on
>> /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0:d fstype
>> ufs
>> panic: vfs_mountroot: cannot mount root
>> rebooting...
>> Resetting ... /
>>
>> maybe the disk is wrong
>> ive try several disk one following these instructions:
>> 1) qemu-img create -f qcow2 file.qcow2 12G
>> 2) Add -drive file=file.qcow2,unit=3 to your qemu startup
>> 3) Boot single user
>> 4) echo
>> 'disk_type="QEMU12.0G":ctlr=SCSI:ncyl=49152:acyl=0:pcyl=49152:nhead=16:nsect=32:rpm=7200'
>>
>> /etc/format.dat
>
> I'd guess these geometry parameters are not correct for your 12G disk.
> It's strange though that the installer kernel sees different geometry
> from the normal boot kernel.
>
>> 5) echo
>> 'partition="QEMU12.0G":disk="QEMU12.0G":ctlr=SCSI:2=0,25165824:0=0,20971520:6=40960,4194304'
>>
>> /etc/format.dat
>
> These could also be wrong, but I have no idea what the numbers mean.
In order not to mess with all this numbers I used a pre-defined 1.3G
disk in the Solaris format utility and created it with dd:
dd if=/dev/zero of=$1 bs=10k count=133756
Otherwise, Ignacio, are you sure that disk0 is your root FS disk and
not something else? Can you post your qemu command line?
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply
* [PATCH 0/7] Cragganmore updates for 3.3
From: Kukjin Kim @ 2011-12-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111129133006.GA26800@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> This patch series is all the pending updates for Cragganmore for 3.3.
> With the exception of the final patch for Littlemill they've all been
> posted before, some a while ago now, but I've not seen any feedback yet.
> They're all available on a git branch in case it's helpful to pull them:
>
> The following changes since commit
> caca6a03d365883564885f2c1da3e88dcf65d139:
>
> Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
> updates/cragganmore
>
> Mark Brown (7):
> ARM: S3C64XX: Raise the frequency of the second I2C bus on
> Cragganmore
> ARM: S3C64XX: Use software initiated powerdown for Cragganmore
> ARM: S3C64XX: Configure WM1250 EV1 GPIOs on Cragganmore
> ARM: S3C64XX: Improve logging of unknown Cragganmore module types
> ARM: S3C64XX: Run Tobermory interrupts in the default mode
> ARM: S3C64XX: Hook up platform data for Kilchomin module on
> Cragganmore
> ARM: S3C64XX: Hook up Littlemill audio card on Cragganmore
>
> arch/arm/mach-s3c64xx/include/mach/crag6410.h | 6 ++-
> arch/arm/mach-s3c64xx/include/mach/irqs.h | 2 +-
> arch/arm/mach-s3c64xx/mach-crag6410-module.c | 56
> +++++++++++++++++++++++-
> arch/arm/mach-s3c64xx/mach-crag6410.c | 30 ++++++++++++-
> 4 files changed, 86 insertions(+), 8 deletions(-)
Looks ok, will apply this series.
And as a note, I'm thinking about the handling of different
IRQ_BOARD_NR...but I'm not sure it is really needed or not :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: S3C64XX: Staticise s3c6400_sysclass
From: Kukjin Kim @ 2011-12-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1322501217-16770-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> The symbol is not exported and doesn't need to be.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> arch/arm/mach-s3c64xx/s3c6400.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/s3c6400.c b/arch/arm/mach-
> s3c64xx/s3c6400.c
> index 7a3bc32..51c00f2 100644
> --- a/arch/arm/mach-s3c64xx/s3c6400.c
> +++ b/arch/arm/mach-s3c64xx/s3c6400.c
> @@ -70,7 +70,7 @@ void __init s3c6400_init_irq(void)
> s3c64xx_init_irq(~0 & ~(0xf << 5), ~0);
> }
>
> -struct sysdev_class s3c6400_sysclass = {
> +static struct sysdev_class s3c6400_sysclass = {
> .name = "s3c6400-core",
> };
>
> --
> 1.7.7.3
Yes! Will apply :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* RE: [RESEND][PATCH] ARM: EXYNOS: Fixed undefined symbol compilation error.
From: Kukjin Kim @ 2011-12-01 10:29 UTC (permalink / raw)
To: 'Pankaj Dubey', linux-samsung-soc; +Cc: linux-arm-kernel
In-Reply-To: <1321352102-10021-1-git-send-email-pankaj.dubey@samsung.com>
Pankaj Dubey wrote:
>
> Many drivers will fail to compile if compiled as module due to
> undefined symbol exynos4_ioremap.
> Fix has been added by exporting the same in cpu.c file.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/cpu.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> index 8e09f34..027f65471 100644
> --- a/arch/arm/mach-exynos/cpu.c
> +++ b/arch/arm/mach-exynos/cpu.c
> @@ -8,6 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/module.h>
> #include <linux/sched.h>
> #include <linux/sysdev.h>
> #include <linux/of.h>
> @@ -164,6 +165,7 @@ void __iomem *exynos4_ioremap(unsigned long phy,
> size_t size, unsigned int type)
>
> return __arm_ioremap(phy, size, type);
> }
> +EXPORT_SYMBOL(exynos4_ioremap);
>
> static void exynos_idle(void)
> {
> --
> 1.7.4.1
Hi Pankaj,
As we discussed internally, since Nicolas Pitre's vmalloc patch series this
can be dropped.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [RESEND][PATCH] ARM: EXYNOS: Fixed undefined symbol compilation error.
From: Kukjin Kim @ 2011-12-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1321352102-10021-1-git-send-email-pankaj.dubey@samsung.com>
Pankaj Dubey wrote:
>
> Many drivers will fail to compile if compiled as module due to
> undefined symbol exynos4_ioremap.
> Fix has been added by exporting the same in cpu.c file.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/cpu.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> index 8e09f34..027f65471 100644
> --- a/arch/arm/mach-exynos/cpu.c
> +++ b/arch/arm/mach-exynos/cpu.c
> @@ -8,6 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/module.h>
> #include <linux/sched.h>
> #include <linux/sysdev.h>
> #include <linux/of.h>
> @@ -164,6 +165,7 @@ void __iomem *exynos4_ioremap(unsigned long phy,
> size_t size, unsigned int type)
>
> return __arm_ioremap(phy, size, type);
> }
> +EXPORT_SYMBOL(exynos4_ioremap);
>
> static void exynos_idle(void)
> {
> --
> 1.7.4.1
Hi Pankaj,
As we discussed internally, since Nicolas Pitre's vmalloc patch series this
can be dropped.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] mm: Ensure that pfn_valid is called once per pageblock when reserving pageblocks
From: Michal Hocko @ 2011-12-01 10:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, KAMEZAWA Hiroyuki, Andrea Arcangeli, David Rientjes,
Dang Bo, Arve Hjønnevåg, KOSAKI Motohiro, John Stultz,
Dave Hansen, linux-mm, linux-kernel
Hi,
the patch bellow fixes a crash during boot (when we set up reserved
page blocks) if zone start_pfn is not block aligned. The issue has
been introduced in 3.0-rc1 by 6d3163ce: mm: check if any page in a
pageblock is reserved before marking it MIGRATE_RESERVE.
I think this is 3.2 and stable material.
---
>From f4da723adb36b247b80283ae520e33726caf485f Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.cz>
Date: Tue, 29 Nov 2011 16:58:38 +0100
Subject: [PATCH] mm: Ensure that pfn_valid is called once per pageblock when
reserving pageblocks
setup_zone_migrate_reserve expects that zone->start_pfn starts
at pageblock_nr_pages aligned pfn otherwise we could access
beyond an existing memblock resulting in the following panic if
CONFIG_HOLES_IN_ZONE is not configured and we do not check pfn_valid:
IP: [<c02d331d>] setup_zone_migrate_reserve+0xcd/0x180
*pdpt = 0000000000000000 *pde = f000ff53f000ff53
Oops: 0000 [#1] SMP
Modules linked in:
Supported: Yes
Pid: 1, comm: swapper Not tainted 3.0.7-0.7-pae #1 VMware, Inc.
VMware Virtual Platform/440BX Desktop Reference Platform
EIP: 0060:[<c02d331d>] EFLAGS: 00010006 CPU: 0
EIP is at setup_zone_migrate_reserve+0xcd/0x180
EAX: 000c0000 EBX: f5801fc0 ECX: 000c0000 EDX: 00000000
ESI: 000c01fe EDI: 000c01fe EBP: 00140000 ESP: f2475f58
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 1, ti=f2474000 task=f2472cd0 task.ti=f2474000)
Stack:
f4000800 00000000 f4000800 000006b8 00000000 000c6cd5 c02d389c 000003b2
00036aa9 00000292 f4000830 c08cfe78 00000000 00000000 c08a76f5 c02d3a1f
c08a771c c08cfe78 c020111b 35310001 00000000 00000000 00000100 f24730c4
Call Trace:
[<c02d389c>] __setup_per_zone_wmarks+0xec/0x160
[<c02d3a1f>] setup_per_zone_wmarks+0xf/0x20
[<c08a771c>] init_per_zone_wmark_min+0x27/0x86
[<c020111b>] do_one_initcall+0x2b/0x160
[<c086639d>] kernel_init+0xbe/0x157
[<c05cae26>] kernel_thread_helper+0x6/0xd
Code: a5 39 f5 89 f7 0f 46 fd 39 cf 76 40 8b 03 f6 c4 08 74 32 eb 91 90 89 c8 c1 e8 0e 0f be 80 80 2f 86 c0 8b 14 85 60 2f 86 c0 89 c8 <2b> 82 b4 12 00 00 c1 e0 05 03 82 ac 12 00 00 8b 00 f6 c4 08 0f
EIP: [<c02d331d>] setup_zone_migrate_reserve+0xcd/0x180 SS:ESP 0068:f2475f58
CR2: 00000000000012b4
---[ end trace 93d72a36b9146f22 ]---
We crashed in pageblock_is_reserved() when accessing pfn 0xc0000 because
highstart_pfn = 0x36ffe.
Make sure that start_pfn is always aligned to pageblock_nr_pages to
ensure that pfn_valid s always called at the start of each pageblock.
Architectures with holes in pageblocks will be correctly handled by
pfn_valid_within in pageblock_is_reserved.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Tested-by: Dang Bo <bdang@vmware.com>
---
mm/page_alloc.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9dd443d..94ff20d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3377,9 +3377,15 @@ static void setup_zone_migrate_reserve(struct zone *zone)
unsigned long block_migratetype;
int reserve;
- /* Get the start pfn, end pfn and the number of blocks to reserve */
+ /*
+ * Get the start pfn, end pfn and the number of blocks to reserve
+ * We have to be careful to be aligned to pageblock_nr_pages to
+ * make sure that we always check pfn_valid for the first page in
+ * the block.
+ */
start_pfn = zone->zone_start_pfn;
end_pfn = start_pfn + zone->spanned_pages;
+ start_pfn = roundup(start_pfn, pageblock_nr_pages);
reserve = roundup(min_wmark_pages(zone), pageblock_nr_pages) >>
pageblock_order;
--
1.7.7.3
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply related
* [PATCH] mm: Ensure that pfn_valid is called once per pageblock when reserving pageblocks
From: Michal Hocko @ 2011-12-01 10:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, KAMEZAWA Hiroyuki, Andrea Arcangeli, David Rientjes,
Dang Bo, Arve Hjønnevåg, KOSAKI Motohiro, John Stultz,
Dave Hansen, linux-mm, linux-kernel
Hi,
the patch bellow fixes a crash during boot (when we set up reserved
page blocks) if zone start_pfn is not block aligned. The issue has
been introduced in 3.0-rc1 by 6d3163ce: mm: check if any page in a
pageblock is reserved before marking it MIGRATE_RESERVE.
I think this is 3.2 and stable material.
---
^ permalink raw reply
* Re: [PATCH 2/5] KVM: MMU: audit: replace mmu audit tracepoint with jump-lable
From: Avi Kivity @ 2011-12-01 10:28 UTC (permalink / raw)
To: Xiao Guangrong; +Cc: Jason Baron, Marcelo Tosatti, LKML, KVM
In-Reply-To: <4ED5FABC.1080705@linux.vnet.ibm.com>
On 11/30/2011 11:43 AM, Xiao Guangrong wrote:
> Subject: [PATCH] KVM: MMU: audit: inline audit function
>
> inline audit function and little cleanup
>
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Time Change Issue Xen 4.1
From: Laszlo Ersek @ 2011-12-01 10:28 UTC (permalink / raw)
To: Niall Fleming
Cc: Jeremy Fitzhardinge, xen-devel@lists.xensource.com, Ian Campbell,
Konrad Rzeszutek Wilk, keir.xen@gmail.com, Jan Beulich,
pbonzini@redhat.com, Konrad Rzeszutek Wilk
In-Reply-To: <1322733206.31810.173.camel@zakaz.uk.xensource.com>
Hello Niall,
On 12/01/11 10:53, Ian Campbell wrote:
> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>> Cheers, at least I know that someone is still looking at it!
>>
>> If someone could give me a general timeframe, like it'll be a month,
>> before we fix it, or two weeks or whatever, I just need to give my
>> line manager something so he gets off my case about it!
>
> I'm afraid OSS software doesn't generally work like that. If you (or
> your boss) wants something fixed on a specific time scale or priority
> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
> sorry but you will just have to wait until someone has the cycles to
> look into this issue.
I shouldn't comment on this, because
- it'll be off-topic, and
- (more importantly) personally I'm not knowledgeable enough to fix the
problem,
but I feel compelled to point out that *in general* it's not about the
various rights accompanying the bits (ie. proprietary / open source /
free software). It's about who gets to allocate whose resources. Under
this aspect it's irrelevant under what rights the end product will be
released, the question is instead who backs the effort & costs of the
end product being hammered into existence.
Users of FLOSS tend to mix up these two things ("what rights do I have
to the code?" vs. "work on this for my sake!"). For the second concept,
commercial relationships are (and have always been) the default, even if
extremely forthcoming FLOSS developers used to evoke a different impression.
(To make it abundantly clear, this is not an advertisment, and I'm
speaking *strictly* personally, for myself alone.)
Laszlo
^ permalink raw reply
* Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
From: Girish K S @ 2011-12-01 10:28 UTC (permalink / raw)
To: Subhash Jadavani; +Cc: linux-mmc, patches, linux-samsung-soc, Chris Ball
In-Reply-To: <000301ccb010$6da0c5c0$48e25140$@org>
On 1 December 2011 15:33, Subhash Jadavani <subhashj@codeaurora.org> wrote:
> Hi Girish,
>
>> -----Original Message-----
>> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
>> owner@vger.kernel.org] On Behalf Of Girish K S
>> Sent: Wednesday, November 30, 2011 2:24 PM
>> To: linux-mmc@vger.kernel.org
>> Cc: patches@linaro.org; linux-samsung-soc@vger.kernel.org;
>> subhashj@codeaurora.org; Girish K S; Chris Ball
>> Subject: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
>>
>> This patch adds the support of the HS200 bus speed for eMMC 4.5
>> devices.
>> The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and
>> host modules have been touched to add support for this module.
>>
>> It is necessary to know the card type in the sdhci.c file to add
>> support
>> for eMMC tuning function. So card.h file is included to import the card
>> data structure.
>>
>> cc: Chris Ball <cjb@laptop.org>
>> Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
>> ---
>> Changes in v5:
>> Reduced the case statements for better code readability. Removed
>> unused macro definitions. Modified the tuning function prototype
>> and definition to support tuning for both SD and eMMC cards.
>> Changes in v4:
>> Rebased onto chris-mmc/mmc-next branch. This patch is
>> successfully
>> applied on commit with id
>> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
>> Changes in v3:
>> In the previous commits of chris-mmc/mmc-next branch, the patch
>> with
>> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
>> caps2 for
>> more capabilities. This patch version deletes the member
>> ext_caps(created
>> in my earlier patch) from struct mmc_host and reuses already
>> accepted
>> caps2 member.
>> Changes in v2:
>> Rebased to latest chris-mmc/mmc-next branch. Resolved indentation
>> problems identified in review. This patch has to be applied
>> before
>> the patch released for modifying the printk messages.
>> Changes in v1:
>> Case statements in switch that produce same result have
>> been combined to reduce repeated assignments.
>> patch recreated after rebase to chris balls mmc-next branch.
>>
>> drivers/mmc/core/bus.c | 3 +-
>> drivers/mmc/core/mmc.c | 77
>> ++++++++++++++++++++++++++++++++++++++++----
>> drivers/mmc/core/sd.c | 3 +-
>> drivers/mmc/core/sdio.c | 4 ++-
>> drivers/mmc/host/sdhci.c | 38 +++++++++++++++++-----
>> include/linux/mmc/card.h | 3 ++
>> include/linux/mmc/host.h | 11 ++++++-
>> include/linux/mmc/mmc.h | 66
>> ++++++++++++++++++++++++++++++++++++++-
>> include/linux/mmc/sdhci.h | 1 +
>> 9 files changed, 185 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>> index 5639fdf..83c9f8d 100644
>> --- a/drivers/mmc/core/bus.c
>> +++ b/drivers/mmc/core/bus.c
>> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
>> mmc_card_ddr_mode(card) ? "DDR " : "",
>> type);
>> } else {
>> - printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
>> + pr_info("%s: new %s%s%s%s card at address %04x\n",
>> mmc_hostname(card->host),
>> mmc_card_uhs(card) ? "ultra high speed " :
>> (mmc_card_highspeed(card) ? "high speed " : ""),
>> + (mmc_card_hs200(card) ? "HS200 " : ""),
>> mmc_card_ddr_mode(card) ? "DDR " : "",
>> type, card->rca);
>> }
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index a1223bd..f4124d6 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -285,6 +285,27 @@ static int mmc_read_ext_csd(struct mmc_card *card,
>> u8 *ext_csd)
>> }
>> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
>> + case EXT_CSD_CARD_TYPE_SDR_ALL:
>> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
>> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
>> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
>> + card->ext_csd.hs_max_dtr = 200000000;
>> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
>> + break;
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
>> + card->ext_csd.hs_max_dtr = 200000000;
>> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
>> + break;
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
>> + card->ext_csd.hs_max_dtr = 200000000;
>> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
>> + break;
>> case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
>> EXT_CSD_CARD_TYPE_26:
>> card->ext_csd.hs_max_dtr = 52000000;
>> @@ -699,6 +720,7 @@ static int mmc_init_card(struct mmc_host *host, u32
>> ocr,
>> {
>> struct mmc_card *card;
>> int err, ddr = 0;
>> + int hs_sdr = 0;
>> u32 cid[4];
>> unsigned int max_dtr;
>> u32 rocr;
>> @@ -894,11 +916,16 @@ static int mmc_init_card(struct mmc_host *host,
>> u32 ocr,
>> /*
>> * Activate high speed (if supported)
>> */
>> - if ((card->ext_csd.hs_max_dtr != 0) &&
>> - (host->caps & MMC_CAP_MMC_HIGHSPEED)) {
>> - err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> - EXT_CSD_HS_TIMING, 1,
>> - card->ext_csd.generic_cmd6_time);
>> + if (card->ext_csd.hs_max_dtr != 0) {
>> + err = 0;
>> + if ((card->ext_csd.hs_max_dtr > 52000000) &&
>> + (host->caps2 & MMC_CAP2_HS200))
>> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> + EXT_CSD_HS_TIMING, 2, 0);
>> + else if (host->caps & MMC_CAP_MMC_HIGHSPEED)
>> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> + EXT_CSD_HS_TIMING, 1, 0);
>> +
>> if (err && err != -EBADMSG)
>> goto free_card;
>>
>> @@ -907,7 +934,11 @@ static int mmc_init_card(struct mmc_host *host,
>> u32 ocr,
>> mmc_hostname(card->host));
>> err = 0;
>> } else {
>> - mmc_card_set_highspeed(card);
>> + if ((card->ext_csd.hs_max_dtr > 52000000) &&
>> + (host->caps2 & MMC_CAP2_HS200))
>> + mmc_card_set_hs200(card);
>> + else
>> + mmc_card_set_highspeed(card);
>> mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
>
> MMC_TIMING_MMC_HS200 is defined but still not used.
>
> So I guess it should be like this ::
> + if ((card->ext_csd.hs_max_dtr > 52000000) &&
> + (host->caps2 & MMC_CAP2_HS200)) {
> + mmc_card_set_hs200(card);
> + mmc_set_timing(card->host, MMC_TIMING_MMC_HS200)
> + } else {
> + mmc_card_set_highspeed(card);
> + mmc_set_timing(card->host,
> MMC_TIMING_MMC_HS)
> + }
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> }
>> }
>> @@ -933,7 +964,7 @@ static int mmc_init_card(struct mmc_host *host, u32
>> ocr,
>> */
>> max_dtr = (unsigned int)-1;
>>
>> - if (mmc_card_highspeed(card)) {
>> + if (mmc_card_highspeed(card) || mmc_card_hs200(card)) {
>> if (max_dtr > card->ext_csd.hs_max_dtr)
>> max_dtr = card->ext_csd.hs_max_dtr;
>> } else if (max_dtr > card->csd.max_dtr) {
>> @@ -959,6 +990,18 @@ static int mmc_init_card(struct mmc_host *host,
>> u32 ocr,
>> }
>>
>> /*
>> + * Indicate HS200 SDR mode (if supported).
>> + */
>> + if (mmc_card_hs200(card)) {
>> + if ((card->ext_csd.card_type & EXT_CSD_CARD_TYPE_SDR_1_8V)
>> + && (host->caps2 & MMC_CAP2_HS200_1_8V_SDR))
>> + hs_sdr = MMC_1_8V_SDR_MODE;
>> + else if ((card->ext_csd.card_type &
>> EXT_CSD_CARD_TYPE_SDR_1_2V)
>> + && (host->caps2 & MMC_CAP2_HS200_1_2V_SDR))
>> + hs_sdr = MMC_1_2V_SDR_MODE;
>> + }
>> +
>> + /*
>> * Activate wide bus and DDR (if supported).
>> */
>> if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
>> @@ -998,6 +1041,17 @@ static int mmc_init_card(struct mmc_host *host,
>> u32 ocr,
>> if (!err) {
>> mmc_set_bus_width(card->host, bus_width);
>>
>> + if ((host->caps2 & MMC_CAP2_HS200) &&
>> + card->host->ops->execute_tuning)
>> + err = card->host->ops-> \
>> + execute_tuning(card->host,
>> +
> MMC_SEND_TUNING_BLOCK_HS200);
>
>
> execute_tuning should be done right after the timing is changed to HS200 and
> clock rate is changed to 200Mhz. This is not the correct sequence to call
> the execute_tuning().
> As told earlier, It is mentioned in the spec that tuning should be executed after change of buswidth (mandatory). Also it mentions that "The host may invoke the HS200 tuning sequence, by sending CMD21 to the device". It means that
after setting the HS200 mode, Changing to freq > 52Mhz and changing
the bus width tuning can be executed anytime to identify the sampling
point to read.(By anytime i mean before actual block read Operation).
Can you please point me to the place in the spec where it specifies
tuning should be done immediately after freq change (may be i missed
to read it).
>> +
>> + if (err) {
>> + pr_warning("tuning execution
> failed\n");
>> + continue;
>> + }
>> +
>> /*
>> * If controller can't handle bus width
> test,
>> * compare ext_csd previously read in 1 bit
>> mode
>> @@ -1056,6 +1110,15 @@ static int mmc_init_card(struct mmc_host *host,
>> u32 ocr,
>> mmc_card_set_ddr_mode(card);
>> mmc_set_timing(card->host, MMC_TIMING_UHS_DDR50);
>> mmc_set_bus_width(card->host, bus_width);
>> + } else if (hs_sdr) {
>> + if (hs_sdr == EXT_CSD_CARD_TYPE_SDR_1_2V) {
>> + err = mmc_set_signal_voltage(host,
>> + MMC_SIGNAL_VOLTAGE_120, 0);
>> + if (err)
>> + goto err;
>> + }
>> + mmc_set_timing(card->host, MMC_TIMING_MMC_HS);
>> + mmc_set_bus_width(card->host, bus_width);
>> }
>> }
>>
>> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
>> index 1d5a3bd..c1d3ee3 100644
>> --- a/drivers/mmc/core/sd.c
>> +++ b/drivers/mmc/core/sd.c
>> @@ -660,7 +660,8 @@ static int mmc_sd_init_uhs_card(struct mmc_card
>> *card)
>>
>> /* SPI mode doesn't define CMD19 */
>> if (!mmc_host_is_spi(card->host) && card->host->ops-
>> >execute_tuning)
>> - err = card->host->ops->execute_tuning(card->host);
>> + err = card->host->ops->execute_tuning(card->host, \
>> +
> MMC_SEND_TUNING_BLOCK);
>>
>> out:
>> kfree(status);
>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>> index 8c04f7f..8ef8817 100644
>> --- a/drivers/mmc/core/sdio.c
>> +++ b/drivers/mmc/core/sdio.c
>> @@ -14,6 +14,7 @@
>>
>> #include <linux/mmc/host.h>
>> #include <linux/mmc/card.h>
>> +#include <linux/mmc/mmc.h>
>> #include <linux/mmc/sdio.h>
>> #include <linux/mmc/sdio_func.h>
>> #include <linux/mmc/sdio_ids.h>
>> @@ -556,7 +557,8 @@ static int mmc_sdio_init_uhs_card(struct mmc_card
>> *card)
>>
>> /* Initialize and start re-tuning timer */
>> if (!mmc_host_is_spi(card->host) && card->host->ops-
>> >execute_tuning)
>> - err = card->host->ops->execute_tuning(card->host);
>> + err = card->host->ops->execute_tuning(card->host,
>> +
> MMC_SEND_TUNING_BLOCK);
>>
>> out:
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index a7c2311..13d74bb 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -49,7 +49,7 @@ static void sdhci_finish_data(struct sdhci_host *);
>>
>> static void sdhci_send_command(struct sdhci_host *, struct mmc_command
>> *);
>> static void sdhci_finish_command(struct sdhci_host *);
>> -static int sdhci_execute_tuning(struct mmc_host *mmc);
>> +static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
>> static void sdhci_tuning_timer(unsigned long data);
>>
>> #ifdef CONFIG_PM_RUNTIME
>> @@ -1016,7 +1016,8 @@ static void sdhci_send_command(struct sdhci_host
>> *host, struct mmc_command *cmd)
>> flags |= SDHCI_CMD_INDEX;
>>
>> /* CMD19 is special in that the Data Present Select should be set
>> */
>> - if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK))
>> + if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
>> + (cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200))
>> flags |= SDHCI_CMD_DATA;
>>
>> sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags),
>> SDHCI_COMMAND);
>> @@ -1287,7 +1288,7 @@ static void sdhci_request(struct mmc_host *mmc,
>> struct mmc_request *mrq)
>> if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>> !(present_state & (SDHCI_DOING_WRITE |
>> SDHCI_DOING_READ))) {
>> spin_unlock_irqrestore(&host->lock, flags);
>> - sdhci_execute_tuning(mmc);
>> + sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>> spin_lock_irqsave(&host->lock, flags);
>>
>> /* Restore original mmc_request structure */
>> @@ -1673,7 +1674,7 @@ static int
>> sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
>> return err;
>> }
>>
>> -static int sdhci_execute_tuning(struct mmc_host *mmc)
>> +static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> {
>> struct sdhci_host *host;
>> u16 ctrl;
>> @@ -1694,10 +1695,13 @@ static int sdhci_execute_tuning(struct mmc_host
>> *mmc)
>> * Host Controller needs tuning only in case of SDR104 mode
>> * and for SDR50 mode when Use Tuning for SDR50 is set in
>> * Capabilities register.
>> + * If the Host Controller supports the HS200 mode then tuning
>> + * function has to be executed.
>> */
>> if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
>> (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
>> - (host->flags & SDHCI_SDR50_NEEDS_TUNING)))
>> + (host->flags & SDHCI_SDR50_NEEDS_TUNING)) ||
>> + (host->flags & SDHCI_HS200_NEEDS_TUNING))
>> ctrl |= SDHCI_CTRL_EXEC_TUNING;
>> else {
>> spin_unlock(&host->lock);
>> @@ -1733,7 +1737,7 @@ static int sdhci_execute_tuning(struct mmc_host
>> *mmc)
>> if (!tuning_loop_counter && !timeout)
>> break;
>>
>> - cmd.opcode = MMC_SEND_TUNING_BLOCK;
>> + cmd.opcode = opcode;
>> cmd.arg = 0;
>> cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
>> cmd.retries = 0;
>> @@ -1748,7 +1752,17 @@ static int sdhci_execute_tuning(struct mmc_host
>> *mmc)
>> * block to the Host Controller. So we set the block size
>> * to 64 here.
>> */
>> - sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
>> SDHCI_BLOCK_SIZE);
>> + if (cmd.opcode == MMC_SEND_TUNING_BLOCK_HS200) {
>> + if (mmc->ios.bus_width == MMC_BUS_WIDTH_8)
>> + sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 128),
>> + SDHCI_BLOCK_SIZE);
>> + else if (mmc->ios.bus_width == MMC_BUS_WIDTH_4)
>> + sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
>> + SDHCI_BLOCK_SIZE);
>> + } else {
>> + sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
>> + SDHCI_BLOCK_SIZE);
>> + }
>>
>> /*
>> * The tuning block is sent by the card to the host
>> controller.
>> @@ -2131,12 +2145,14 @@ static void sdhci_show_adma_error(struct
>> sdhci_host *host) { }
>>
>> static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
>> {
>> + u32 command;
>> BUG_ON(intmask == 0);
>>
>> /* CMD19 generates _only_ Buffer Read Ready interrupt */
>> if (intmask & SDHCI_INT_DATA_AVAIL) {
>> - if (SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND)) ==
>> - MMC_SEND_TUNING_BLOCK) {
>> + command = SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND));
>> + if ((command == MMC_SEND_TUNING_BLOCK) ||
>> + (command == MMC_SEND_TUNING_BLOCK_HS200)) {
>> host->tuning_done = 1;
>> wake_up(&host->buf_ready_int);
>> return;
>> @@ -2741,6 +2757,10 @@ int sdhci_add_host(struct sdhci_host *host)
>> if (caps[1] & SDHCI_USE_SDR50_TUNING)
>> host->flags |= SDHCI_SDR50_NEEDS_TUNING;
>>
>> + /* Does the host needs tuning for HS200? */
>> + if (mmc->caps2 & MMC_CAP2_HS200)
>> + host->flags |= SDHCI_HS200_NEEDS_TUNING;
>> +
>> /* Driver Type(s) (A, C, D) supported by the host */
>> if (caps[1] & SDHCI_DRIVER_TYPE_A)
>> mmc->caps |= MMC_CAP_DRIVER_TYPE_A;
>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>> index 534974c..e76f649 100644
>> --- a/include/linux/mmc/card.h
>> +++ b/include/linux/mmc/card.h
>> @@ -209,6 +209,7 @@ struct mmc_card {
>> #define MMC_STATE_HIGHSPEED_DDR (1<<4) /* card is in high
>> speed mode */
>> #define MMC_STATE_ULTRAHIGHSPEED (1<<5) /* card is in ultra
>> high speed mode */
>> #define MMC_CARD_SDXC (1<<6) /* card is SDXC */
>> +#define MMC_STATE_HIGHSPEED_200 (1<<7) /* card is in HS200
>> mode */
>> unsigned int quirks; /* card quirks */
>> #define MMC_QUIRK_LENIENT_FN0 (1<<0) /* allow SDIO FN0
>> writes outside of the VS CCCR range */
>> #define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (1<<1) /* use func-
>> >cur_blksize */
>> @@ -365,6 +366,7 @@ static inline void __maybe_unused
>> remove_quirk(struct mmc_card *card, int data)
>> #define mmc_card_present(c) ((c)->state & MMC_STATE_PRESENT)
>> #define mmc_card_readonly(c) ((c)->state & MMC_STATE_READONLY)
>> #define mmc_card_highspeed(c) ((c)->state & MMC_STATE_HIGHSPEED)
>> +#define mmc_card_hs200(c) ((c)->state & MMC_STATE_HIGHSPEED_200)
>> #define mmc_card_blockaddr(c) ((c)->state & MMC_STATE_BLOCKADDR)
>> #define mmc_card_ddr_mode(c) ((c)->state & MMC_STATE_HIGHSPEED_DDR)
>> #define mmc_card_uhs(c) ((c)->state &
>> MMC_STATE_ULTRAHIGHSPEED)
>> @@ -374,6 +376,7 @@ static inline void __maybe_unused
>> remove_quirk(struct mmc_card *card, int data)
>> #define mmc_card_set_present(c) ((c)->state |= MMC_STATE_PRESENT)
>> #define mmc_card_set_readonly(c) ((c)->state |= MMC_STATE_READONLY)
>> #define mmc_card_set_highspeed(c) ((c)->state |= MMC_STATE_HIGHSPEED)
>> +#define mmc_card_set_hs200(c) ((c)->state |=
>> MMC_STATE_HIGHSPEED_200)
>> #define mmc_card_set_blockaddr(c) ((c)->state |= MMC_STATE_BLOCKADDR)
>> #define mmc_card_set_ddr_mode(c) ((c)->state |=
>> MMC_STATE_HIGHSPEED_DDR)
>> #define mmc_card_set_uhs(c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED)
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index 706f722..5eac57a 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -50,6 +50,7 @@ struct mmc_ios {
>>
>> #define MMC_TIMING_LEGACY 0
>> #define MMC_TIMING_MMC_HS 1
>> +#define MMC_TIMING_MMC_HS200 2
>> #define MMC_TIMING_SD_HS 2
>> #define MMC_TIMING_UHS_SDR12 MMC_TIMING_LEGACY
>> #define MMC_TIMING_UHS_SDR25 MMC_TIMING_SD_HS
>> @@ -60,6 +61,8 @@ struct mmc_ios {
>> #define MMC_SDR_MODE 0
>> #define MMC_1_2V_DDR_MODE 1
>> #define MMC_1_8V_DDR_MODE 2
>> +#define MMC_1_2V_SDR_MODE 3
>> +#define MMC_1_8V_SDR_MODE 4
>>
>> unsigned char signal_voltage; /* signalling voltage
>> (1.8V or 3.3V) */
>>
>> @@ -148,7 +151,9 @@ struct mmc_host_ops {
>> void (*init_card)(struct mmc_host *host, struct mmc_card *card);
>>
>> int (*start_signal_voltage_switch)(struct mmc_host *host,
>> struct mmc_ios *ios);
>> - int (*execute_tuning)(struct mmc_host *host);
>> +
>> + /* The tuning command opcode value is different for SD and eMMC
>> cards */
>> + int (*execute_tuning)(struct mmc_host *host, u32 opcode);
>> void (*enable_preset_value)(struct mmc_host *host, bool enable);
>> int (*select_drive_strength)(unsigned int max_dtr, int
>> host_drv, int card_drv);
>> void (*hw_reset)(struct mmc_host *host);
>> @@ -242,6 +247,10 @@ struct mmc_host {
>> #define MMC_CAP2_CACHE_CTRL (1 << 1) /* Allow cache control */
>> #define MMC_CAP2_POWEROFF_NOTIFY (1 << 2) /* Notify poweroff
>> supported */
>> #define MMC_CAP2_NO_MULTI_READ (1 << 3) /* Multiblock reads
>> don't work */
>> +#define MMC_CAP2_HS200_1_8V_SDR (1 << 4) /* can support */
>> +#define MMC_CAP2_HS200_1_2V_SDR (1 << 5) /* can support */
>> +#define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
>> + MMC_CAP2_HS200_1_2V_SDR)
>>
>> mmc_pm_flag_t pm_caps; /* supported pm features */
>> unsigned int power_notify_type;
>> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
>> index 0e71356..7996272 100644
>> --- a/include/linux/mmc/mmc.h
>> +++ b/include/linux/mmc/mmc.h
>> @@ -51,6 +51,7 @@
>> #define MMC_READ_SINGLE_BLOCK 17 /* adtc [31:0] data addr R1
>> */
>> #define MMC_READ_MULTIPLE_BLOCK 18 /* adtc [31:0] data addr R1
>> */
>> #define MMC_SEND_TUNING_BLOCK 19 /* adtc R1
>> */
>> +#define MMC_SEND_TUNING_BLOCK_HS200 21 /* adtc R1 */
>>
>> /* class 3 */
>> #define MMC_WRITE_DAT_UNTIL_STOP 20 /* adtc [31:0] data addr R1
>> */
>> @@ -333,13 +334,76 @@ struct _mmc_csd {
>>
>> #define EXT_CSD_CARD_TYPE_26 (1<<0) /* Card can run at 26MHz */
>> #define EXT_CSD_CARD_TYPE_52 (1<<1) /* Card can run at 52MHz */
>> -#define EXT_CSD_CARD_TYPE_MASK 0xF /* Mask out reserved bits */
>> +#define EXT_CSD_CARD_TYPE_MASK 0x3F /* Mask out reserved bits */
>> #define EXT_CSD_CARD_TYPE_DDR_1_8V (1<<2) /* Card can run at 52MHz
>> */
>> /* DDR mode @1.8V or 3V I/O */
>> #define EXT_CSD_CARD_TYPE_DDR_1_2V (1<<3) /* Card can run at 52MHz
>> */
>> /* DDR mode @1.2V I/O */
>> #define EXT_CSD_CARD_TYPE_DDR_52 (EXT_CSD_CARD_TYPE_DDR_1_8V \
>> | EXT_CSD_CARD_TYPE_DDR_1_2V)
>> +#define EXT_CSD_CARD_TYPE_SDR_1_8V (1<<4) /* Card can run at
>> 200MHz */
>> +#define EXT_CSD_CARD_TYPE_SDR_1_2V (1<<5) /* Card can run at
>> 200MHz */
>> + /* SDR mode @1.2V I/O */
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_200 (EXT_CSD_CARD_TYPE_SDR_1_8V \
>> + | EXT_CSD_CARD_TYPE_SDR_1_2V)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_ALL (EXT_CSD_CARD_TYPE_SDR_200 \
>> + | EXT_CSD_CARD_TYPE_52 \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_2V_ALL
>> (EXT_CSD_CARD_TYPE_SDR_1_2V \
>> + | EXT_CSD_CARD_TYPE_52 \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_8V_ALL
>> (EXT_CSD_CARD_TYPE_SDR_1_8V \
>> + | EXT_CSD_CARD_TYPE_52 \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V
>> (EXT_CSD_CARD_TYPE_SDR_1_2V \
>> + | EXT_CSD_CARD_TYPE_DDR_1_8V
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V
>> (EXT_CSD_CARD_TYPE_SDR_1_8V \
>> + | EXT_CSD_CARD_TYPE_DDR_1_8V
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V
>> (EXT_CSD_CARD_TYPE_SDR_1_2V \
>> + | EXT_CSD_CARD_TYPE_DDR_1_2V
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V
>> (EXT_CSD_CARD_TYPE_SDR_1_8V \
>> + | EXT_CSD_CARD_TYPE_DDR_1_2V
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52
>> (EXT_CSD_CARD_TYPE_SDR_1_2V \
>> + | EXT_CSD_CARD_TYPE_DDR_52
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52
>> (EXT_CSD_CARD_TYPE_SDR_1_8V \
>> + | EXT_CSD_CARD_TYPE_DDR_52
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V
>> (EXT_CSD_CARD_TYPE_SDR_200 \
>> + | EXT_CSD_CARD_TYPE_DDR_1_8V
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V
>> (EXT_CSD_CARD_TYPE_SDR_200 \
>> + | EXT_CSD_CARD_TYPE_DDR_1_2V
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>> +
>> +#define EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52 (EXT_CSD_CARD_TYPE_SDR_200
>> \
>> + | EXT_CSD_CARD_TYPE_DDR_52
> \
>> + | EXT_CSD_CARD_TYPE_52
> \
>> + | EXT_CSD_CARD_TYPE_26)
>>
>> #define EXT_CSD_BUS_WIDTH_1 0 /* Card is in 1 bit mode */
>> #define EXT_CSD_BUS_WIDTH_4 1 /* Card is in 4 bit mode */
>> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
>> index e4b6935..d9a2222 100644
>> --- a/include/linux/mmc/sdhci.h
>> +++ b/include/linux/mmc/sdhci.h
>> @@ -121,6 +121,7 @@ struct sdhci_host {
>> #define SDHCI_AUTO_CMD23 (1<<7) /* Auto CMD23 support */
>> #define SDHCI_PV_ENABLED (1<<8) /* Preset value enabled */
>> #define SDHCI_SDIO_IRQ_ENABLED (1<<9) /* SDIO irq enabled */
>> +#define SDHCI_HS200_NEEDS_TUNING (1<<10) /* HS200 needs tuning */
>>
>> unsigned int version; /* SDHCI spec. version */
>>
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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
* [PATCH] fs: Make write(2) interruptible by a fatal signal
From: Jan Kara @ 2011-12-01 10:27 UTC (permalink / raw)
To: LKML; +Cc: linux-fsdevel, Andrew Morton, Linus Torvalds, Wu Fengguang,
Jan Kara
Currently write(2) to a file is not interruptible by any signal. Sometimes this
is desirable (e.g. when you want to quickly kill a process hogging your disk or
when some process gets blocked in balance_dirty_pages() indefinitely due to a
filesystem being in an error condition). This patch makes write interruptible
by SIGKILL. We do not allow write to be interruptible by any other signal
because that has larger potential of screwing some badly written applications.
Reported-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Tested-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
mm/filemap.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
Resending this patch to allow people outside linux-fsdevel to take part
in the discussion...
diff --git a/mm/filemap.c b/mm/filemap.c
index c0018f2..c106d3b 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2407,7 +2407,6 @@ static ssize_t generic_perform_write(struct file *file,
iov_iter_count(i));
again:
-
/*
* Bring in the user page that we will copy from _first_.
* Otherwise there's a nasty deadlock on copying from the
@@ -2463,7 +2462,10 @@ again:
written += copied;
balance_dirty_pages_ratelimited(mapping);
-
+ if (fatal_signal_pending(current)) {
+ status = -EINTR;
+ break;
+ }
} while (iov_iter_count(i));
return written ? written : status;
--
1.7.1
^ permalink raw reply related
* need help for locking with nfs4
From: Upendra Moturi @ 2011-12-01 10:13 UTC (permalink / raw)
To: linux-nfs
Hi
I need some example to configure nfs4 mandatory locking.
I have setup nfs4 server and client.
I want to enable mandatory locking so that no two clients can access
file at same time.
Please guide me.
I working on ubuntu 10.04 and kernel 2.6.32-21-server.
--
Thanks and Regards,
Upendra.M
As a leading developer of IT infrastructure software solutions,
Hexagrid developed the first cloud computing platform that directly
aligns with the real-world IT delivery models of both solution
providers and enterprises. Hexagrid provides all the software and
support that IT organizations need to successfully build public,
private, or hybrid clouds that fit their specific business and
end-user requirements. Hexagrid cloud solutions truly simplify and
expedite virtual IT management, empowering successful cloud computing
strategies that quickly increase profits by pooling resources,
delivering control, and building value. Our Software, Your Cloud. For
more information, visit www.hexagrid.com and follow @Hexagrid on
Twitter
^ permalink raw reply
* [PATCH] x86-64/mmcfg: remove __initdata annotation overlooked in 23749:e8d1c8f074ba
From: Jan Beulich @ 2011-12-01 10:26 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -23,7 +23,7 @@ struct mmcfg_virt {
char __iomem *virt;
};
static struct mmcfg_virt *pci_mmcfg_virt;
-static int __initdata mmcfg_pci_segment_shift;
+static unsigned int mmcfg_pci_segment_shift;
static char __iomem *get_virt(unsigned int seg, unsigned int *bus)
{
[-- Attachment #2: x86_64-mmcfg-fix-23749.patch --]
[-- Type: text/plain, Size: 497 bytes --]
x86-64/mmcfg: remove __initdata annotation overlooked in 23749:e8d1c8f074ba
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -23,7 +23,7 @@ struct mmcfg_virt {
char __iomem *virt;
};
static struct mmcfg_virt *pci_mmcfg_virt;
-static int __initdata mmcfg_pci_segment_shift;
+static unsigned int mmcfg_pci_segment_shift;
static char __iomem *get_virt(unsigned int seg, unsigned int *bus)
{
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:26 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Arnd Bergmann, xen-devel@lists.xensource.com,
linaro-dev@lists.linaro.org, Pawel Moll, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
android-virt@lists.cs.columbia.edu,
embeddedxen-devel@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:
>
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> >
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
>
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.
I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.
The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.
Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.
Ian.
^ permalink raw reply
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Michael S. Tsirkin @ 2011-12-01 10:26 UTC (permalink / raw)
To: Sasha Levin; +Cc: markmc, kvm, linux-kernel, virtualization, Avi Kivity
In-Reply-To: <1322726977.3259.3.camel@lappy>
On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 01, 2011 at 01:12:25PM +1030, Rusty Russell wrote:
> > > On Wed, 30 Nov 2011 18:11:51 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> > > > On Tue, 2011-11-29 at 16:58 +0200, Avi Kivity wrote:
> > > > > On 11/29/2011 04:54 PM, Michael S. Tsirkin wrote:
> > > > > > >
> > > > > > > Which is actually strange, weren't indirect buffers introduced to make
> > > > > > > the performance *better*? From what I see it's pretty much the
> > > > > > > same/worse for virtio-blk.
> > > > > >
> > > > > > I know they were introduced to allow adding very large bufs.
> > > > > > See 9fa29b9df32ba4db055f3977933cd0c1b8fe67cd
> > > > > > Mark, you wrote the patch, could you tell us which workloads
> > > > > > benefit the most from indirect bufs?
> > > > > >
> > > > >
> > > > > Indirects are really for block devices with many spindles, since there
> > > > > the limiting factor is the number of requests in flight. Network
> > > > > interfaces are limited by bandwidth, it's better to increase the ring
> > > > > size and use direct buffers there (so the ring size more or less
> > > > > corresponds to the buffer size).
> > > > >
> > > >
> > > > I did some testing of indirect descriptors under different workloads.
> > >
> > > MST and I discussed getting clever with dynamic limits ages ago, but it
> > > was down low on the TODO list. Thanks for diving into this...
> > >
> > > AFAICT, if the ring never fills, direct is optimal. When the ring
> > > fills, indirect is optimal (we're better to queue now than later).
> > >
> > > Why not something simple, like a threshold which drops every time we
> > > fill the ring?
> > >
> > > struct vring_virtqueue
> > > {
> > > ...
> > > int indirect_thresh;
> > > ...
> > > }
> > >
> > > virtqueue_add_buf_gfp()
> > > {
> > > ...
> > >
> > > if (vq->indirect &&
> > > (vq->vring.num - vq->num_free) + out + in > vq->indirect_thresh)
> > > return indirect()
> > > ...
> > >
> > > if (vq->num_free < out + in) {
> > > if (vq->indirect && vq->indirect_thresh > 0)
> > > vq->indirect_thresh--;
> > >
> > > ...
> > > }
> > >
> > > Too dumb?
> > >
> > > Cheers,
> > > Rusty.
> >
> > We'll presumably need some logic to increment is back,
> > to account for random workload changes.
> > Something like slow start?
>
> We can increment it each time the queue was less than 10% full, it
> should act like slow start, no?
No, we really shouldn't get an empty ring as long as things behave
well. What I meant is something like:
#define VIRTIO_DECREMENT 2
#define VIRTIO_INCREMENT 1
if (vq->num_free < out + in) {
if (vq->indirect && vq->indirect_thresh > VIRTIO_DECREMENT)
vq->indirect_thresh /= VIRTIO_DECREMENT;
} else {
if (vq->indirect_thresh < vq->num)
vq->indirect_thresh += VIRTIO_INCREMENT;
}
So we try to avoid indirect but the moment there's no space, we decrease
the threshold drastically. If you make the increment/decrement module
parameters it's easy to try different values.
> --
>
> Sasha.
^ permalink raw reply
* Re: [bug?] r8169: hangs under heavy load
From: Francois Romieu @ 2011-12-01 10:20 UTC (permalink / raw)
To: booster
Cc: hayeswang, 'Jonathan Nieder', 'Eric Dumazet',
netdev, 'nic_swsd', linux-kernel, 'Armin Kazmi'
In-Reply-To: <4ED538EC.4010509@wolke7.net>
booster@wolke7.net <booster@wolke7.net> :
[...]
> Any more ideas ?
Give me a brain.
Fixed patch below.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f06aa1..e776bf2 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4885,8 +4894,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
RTL_W16(IntrMitigate, 0x5151);
/* Work around for RxFIFO overflow. */
- if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_22) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
tp->intr_event |= RxFIFOOver | PCSTimeout;
tp->intr_event &= ~RxOverflow;
}
@@ -5804,6 +5812,10 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
*/
status = RTL_R16(IntrStatus);
while (status && status != 0xffff) {
+ status &= tp->intr_event;
+ if (!status)
+ break;
+
handled = 1;
/* Handle all of the error cases first. These will reset
@@ -5818,7 +5830,6 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
switch (tp->mac_version) {
/* Work around for rx fifo overflow */
case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_26:
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
@@ -5828,6 +5839,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
case RTL_GIGA_MAC_VER_19:
case RTL_GIGA_MAC_VER_20:
case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_27:
^ permalink raw reply related
* [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:
>
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> >
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
>
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.
I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.
The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.
Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.
Ian.
^ permalink raw reply
* Re: [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:26 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
Arnd Bergmann, Pawel Moll, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
android-virt@lists.cs.columbia.edu, kvm@vger.kernel.org,
embeddedxen-devel@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:
>
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> >
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
>
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.
I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.
The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.
Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.
Ian.
^ permalink raw reply
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Michael S. Tsirkin @ 2011-12-01 10:26 UTC (permalink / raw)
To: Sasha Levin
Cc: Rusty Russell, Avi Kivity, linux-kernel, virtualization, kvm,
markmc
In-Reply-To: <1322726977.3259.3.camel@lappy>
On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 01, 2011 at 01:12:25PM +1030, Rusty Russell wrote:
> > > On Wed, 30 Nov 2011 18:11:51 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> > > > On Tue, 2011-11-29 at 16:58 +0200, Avi Kivity wrote:
> > > > > On 11/29/2011 04:54 PM, Michael S. Tsirkin wrote:
> > > > > > >
> > > > > > > Which is actually strange, weren't indirect buffers introduced to make
> > > > > > > the performance *better*? From what I see it's pretty much the
> > > > > > > same/worse for virtio-blk.
> > > > > >
> > > > > > I know they were introduced to allow adding very large bufs.
> > > > > > See 9fa29b9df32ba4db055f3977933cd0c1b8fe67cd
> > > > > > Mark, you wrote the patch, could you tell us which workloads
> > > > > > benefit the most from indirect bufs?
> > > > > >
> > > > >
> > > > > Indirects are really for block devices with many spindles, since there
> > > > > the limiting factor is the number of requests in flight. Network
> > > > > interfaces are limited by bandwidth, it's better to increase the ring
> > > > > size and use direct buffers there (so the ring size more or less
> > > > > corresponds to the buffer size).
> > > > >
> > > >
> > > > I did some testing of indirect descriptors under different workloads.
> > >
> > > MST and I discussed getting clever with dynamic limits ages ago, but it
> > > was down low on the TODO list. Thanks for diving into this...
> > >
> > > AFAICT, if the ring never fills, direct is optimal. When the ring
> > > fills, indirect is optimal (we're better to queue now than later).
> > >
> > > Why not something simple, like a threshold which drops every time we
> > > fill the ring?
> > >
> > > struct vring_virtqueue
> > > {
> > > ...
> > > int indirect_thresh;
> > > ...
> > > }
> > >
> > > virtqueue_add_buf_gfp()
> > > {
> > > ...
> > >
> > > if (vq->indirect &&
> > > (vq->vring.num - vq->num_free) + out + in > vq->indirect_thresh)
> > > return indirect()
> > > ...
> > >
> > > if (vq->num_free < out + in) {
> > > if (vq->indirect && vq->indirect_thresh > 0)
> > > vq->indirect_thresh--;
> > >
> > > ...
> > > }
> > >
> > > Too dumb?
> > >
> > > Cheers,
> > > Rusty.
> >
> > We'll presumably need some logic to increment is back,
> > to account for random workload changes.
> > Something like slow start?
>
> We can increment it each time the queue was less than 10% full, it
> should act like slow start, no?
No, we really shouldn't get an empty ring as long as things behave
well. What I meant is something like:
#define VIRTIO_DECREMENT 2
#define VIRTIO_INCREMENT 1
if (vq->num_free < out + in) {
if (vq->indirect && vq->indirect_thresh > VIRTIO_DECREMENT)
vq->indirect_thresh /= VIRTIO_DECREMENT;
} else {
if (vq->indirect_thresh < vq->num)
vq->indirect_thresh += VIRTIO_INCREMENT;
}
So we try to avoid indirect but the moment there's no space, we decrease
the threshold drastically. If you make the increment/decrement module
parameters it's easy to try different values.
> --
>
> Sasha.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 05/18] qdev: provide a path resolution
From: Stefan Hajnoczi @ 2011-12-01 10:24 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, Peter Maydell, Stefan Hajnoczi, Jan Kiszka,
qemu-devel, Markus Armbruster, Luiz Capitulino
In-Reply-To: <1322687028-29714-6-git-send-email-aliguori@us.ibm.com>
On Wed, Nov 30, 2011 at 03:03:35PM -0600, Anthony Liguori wrote:
> +DeviceState *qdev_resolve_path(const char *path, bool *ambiguous)
> +{
> + bool partial_path = true;
> + DeviceState *dev;
> + gchar **parts;
> +
> + parts = g_strsplit(path, "/", 0);
> + if (parts == NULL || parts[0] == NULL) {
We must g_strfreev(parts) in the parts[0] == NULL case.
> +/**
> + * @qdev_resolve_path - resolves a path returning a device
> + *
> + * There are two types of supported paths--absolute paths and partial paths.
> + *
> + * Absolute paths are derived from the root device and can follow child<> or
> + * link<> properties. Since they can follow link<> properties, they can be
> + * arbitrarily long. Absolute paths look like absolute filenames and are prefix
s/prefix/prefixed/
> + * with a leading slash.
> + *
> + * Partial paths are look like relative filenames. They do not begin with a
s/are//
> + * prefix. The matching rules for partial paths are subtle but designed to make
> + * specifying devices easy. At each level of the composition tree, the partial
> + * path is matched as an absolute path. The first match is not returned. At
> + * least two matches are searched for. A successful result is only returned if
> + * only one match is founded. If more than one match is found, a flag is return
s/return/returned/
> + * to indicate that the match was ambiguous.
> + *
> + * @path - the path to resolve
> + *
> + * @ambiguous - returns true if the path resolution failed because of an
> + * ambiguous match
The implementation seems to depend on ambiguous being initialized to
false by the caller. That would be worth documenting or changing so it
does not depend on the initial value.
> + *
> + * Returns:
> + * The matched device.
The matched device or NULL on path lookup failure.
^ permalink raw reply
* Re: Permission for xenstore operation on HVM
From: Ian Campbell @ 2011-12-01 10:24 UTC (permalink / raw)
To: sandr8@gmail.com
Cc: xen-devel@lists.xensource.com, duolvxendev, Vasiliy Tolstov
In-Reply-To: <CAJeBh4sWv-4ZHaYWBQSKb91hzsXno4XM+4eQ8ZVVoX3zjU8B=A@mail.gmail.com>
On Thu, 2011-12-01 at 10:16 +0000, Alessandro Salvatori wrote:
> On Thu, Dec 1, 2011 at 01:45, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
> > In HVM mode You allow write to /local/domain/$DOMID/data
>
> do you mean that in PV mode one can write to vm-data, and in HVM mode
> one can write to data?
With the xl toolstack it is "data" in both cases. I can't speak for
other toolstacks but it would be nice if they were all consistent...
> in fact in my first message that never went through I had two
> theories, and I chopped the first one because I was thinking it
> sounded too ridiculous of me to say :)
>
> > theory 1: for HVM guests Xen gives the ownership of the xenstore variables
> > to dom0 instead of the domU that is running the guest. My humble guess is
> > that Xen assumes that HVM guests are gonna be hypervisor agnostic and
> > not gonna be using xenstore. Of course this assumption breaks when you
> > have PV-HVM guests.
>
> of course, if that is the case, then at provisioning time one wouldn't
> know an HVM guest is gonna actually become a PV-HVM... so it will
> still be treated as an HVM guest... sigh...
>
> now, I wonder: can one get the data directory through XAPI though?
If you are running xapi then xen-api@lists.xensource.com is the correct
place to ask for help.
Ian.
>
> thanks!
> -Alessandro-
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other techniques
From: Alexander Graf @ 2011-12-01 10:23 UTC (permalink / raw)
To: 陳韋任; +Cc: qemu-devel
In-Reply-To: <20111201035024.GA88545@cs.nctu.edu.tw>
On 01.12.2011, at 04:50, 陳韋任 wrote:
> Hi Alex,
>
>> Very cool! I was thinking about this for a while myself now. It's especially appealing these days since you can do the hotspot optimization in a separate thread :).
>>
>> Especially in system mode, you also need to flush when tb_flush() is called though. And you have to make sure to match hflags and segment descriptors for the links - otherwise you might end up connecting TBs from different processes :).
>
> I'll check the tb_flush again. IIRC, we make the code cache big enough so that
> there is no need to flush the code cache. But I think we still need to deal with
> it in the end.
It is never big enough :). In fact, even a normal system mode guest boot triggers tb_flush usually because the cache is full. And target code can also trigger it manually.
> The block linking is done by QEMU and we leave it alone. But I don't know QEMU
> ever does hflags and segment descriptors check before doing block linking. Could
> you point it out? Anyway, here is how we form trace from a set of basic blocks.
Sure. Just check for every piece of code that executes cpu_get_tb_cpu_state() :).
> 1. We insert instrumented code at the beginning of each TCG block to collect how
> many times this block being executed.
>
> 2. When a block's execution time, say block A, reaches a pre-defined threshold,
> we follow the run time execution path to collect block B followed A and so on
> to form a trace. This approach is called NET (Next-Executing Tail) [1].
>
> 3. Then a trace composed of TCG blocks is sent to a LLVM translator. The translator
> generates the host binary for the trace into a LLVM code cache, and patch the
I don't fully understand this part. Do you disassemble the x86 blob that TCG emitted?
> beginning of block A (in QEMU code cache) so that anyone executing block A will
> jump to the corresponding trace and execute.
>
> Above is block to trace link. I think there is no need to do hflags and segment
> descriptors check, right? Although I set the trace length to one basic block at
If you only take the choices that QEMU has already patched into the TB for you then no, you don't need to check it yourself, because QEMU already checked it :)
> the moment (make the situation simpler), I think we still don't have to check
> the blocks' hflags and segment descriptors in the trace to see if they match.
Yeah. You only need to be sync'ed with the invalidation then. And make sure you patch the TB atomically, so you don't have a separate thread accidentally run half your code and half the old code.
>
>>> successfully, then login and run some benchmark on it. As a very first step, we
>>> make a very high threshold on trace building. In other words, a basic block must
>>> be executed *many* time to trigger the trace building process. Then we lower the
>>> threshold a bit at a time to see how things work. When something goes wrong, we
>>> might get kernel panic or the system hangs at some point on the booting process.
>>> I have no idea on how to solve this kind of problem. So I'd like to seek for
>>> help/experience/suggestion on the mailing list. I just hope I make the whole
>>> situation clear to you.
>>
>> I don't see any better approach to debugging this than the one you're already taking. Try to run as many workloads as you can and see if they break :). Oh and always make the optimization optional, so that you can narrow it down to it and know you didn't hit a generic QEMU bug.
>
> You mean make the trace optimization optional? We have tested our framework in
> LLVM-only mode. which means we replace TCG with LLVM entirely. It's _very_ slow
I was more thinking of making the trace optimization optional as in not optimize but do only TCG like it's done today :).
> but works. What the generic QEMU bug is? We use QEMU 0.13 and just rely on its
> emulation part right now. Does recent version fix major bugs in the emulation
> engine?
I don't know - there are always bug fixes in areas all over the code base. But I guess the parts you've been touching have been pretty stable. Either way, I was really more trying to point out that there could always be bugs in any layer, so having the ability to turn off a layer is in general a good idea :).
Alex
^ 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.