Re: [PATCH 1/3] arch/tile: implement user_regset interface on tilegx
On Mon, Dec 17, 2012 at 12:06 PM, Chris Metcalf wrote:
> On 12/14/2012 11:34 PM, Simon Marchi wrote:
>> This is an implementation of user_regset for the tilegx architecture. It
>> reuses the basic blocks that were already there.
>
> Thanks, Simon! A couple of comments:
>
> I encourage you to respin this for tilepro as well as tilegx, since it's
> going to be trivial to make it happen. Just take away all yours ifdefs, and
> use #include and CHIP_ARCH_NAME instead of the string "tilegx".
> It's worth it just to avoid the ifdefs in the code :-)
Ok, I will send a v2 with this soon.
> I think with this support added, we have all the prerequisites to add "select
> HAVE_ARCH_TRACEHOOK" under "config TILE" in arch/tile/Kconfig, so we might as
> well do that too. That will enable PTRACE_GETREGSET and PTRACE_SETREGSET, as
> well as /proc/PID/syscall, so why not?
This is indeed my objective ;), and it is an intermediate objective to
add support for HAVE_SYSCALL_TRACEPOINTS. If we look at arch/Kconfig,
just above HAVE_ARCH_TRACEHOOK, we still have
TIF_SYSCALL_TRACE calls tracehook_report_syscall_{entry,exit}
TIF_NOTIFY_RESUME calls tracehook_notify_resume()
signal delivery calls tracehook_signal_handler()
that we need to implement.
> --
> Chris Metcalf, Tilera Corp.
> http://www.tilera.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI: Overriding ACPI tables via initrd only works with an initrd
On Monday, December 17, 2012 10:08:52 AM H. Peter Anvin wrote: > On 12/17/2012 01:28 AM, Borislav Petkov wrote: > > Hi guys, > > > > this one sanitizes the Kconfig entry prompt so can we pick it up for > > -rc1 or later, please? > > Hm... all these are actually cleanups or fixes for the stuff that is now > upstream, I believe... as minor fixes I think these can be pushed > post-rc1 if we don't get to them sooner but it looks like they are all > needed. This and another one are more or less minor cleanups, not urgently needed. I can repost them the next days. Thanks hpa for helping to finally get this feature mainline. It's a huge enhancement for developing and debugging ACPI related stuff on Linux. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, 17 Dec 2012, Greg KH wrote: > You can't pick anything up for 3.9 until after 3.8-rc1 is out, according > to the rules of linux-next Well, you can accept a submission and store it in a private tree until then. You just can't put it in any tree that feeds into linux-next. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, 17 Dec 2012, Stephen Warren wrote: > On 12/13/2012 11:59 PM, Venu Byravarasu wrote: > > As Tegra USB host driver is using instance number for resetting > > PORT0 twice, adding a new DT property for handling this. > > Alan, Greg, Felip,e > > This series looks fine to me. > > I'd like to take all the Tegra-related USB patches through the Tegra > tree for 3.9 if possible (so I'm looking for your acks here). I believe > Venu plans to significantly clean up the EHCI/PHY driver split for > Tegra, rework the drivers, and add support for Tegra30 in addition to > Tegra20. Some of this requires changes to some Tegra board files and > device trees to maintain "git bisect" I don't know for sure yet, but I > believe that rework may also end up conflicting with other clock-related > rework that will show up for Tegra in 3.9. Are you OK with this? I'll > certainly look for your review/acks on the patches before picking them > up though. Regarding the changes to drivers/usb/host/ehci-tegra.c: Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 02:58 PM, Mitch Bradley wrote: > On 12/17/2012 11:36 AM, Stephen Warren wrote: >> On 12/17/2012 05:10 AM, Laxman Dewangan wrote: >>> Nvidia's Tegra has multiple uart controller which supports: >>> - APB dma based controller fifo read/write. >>> - End Of Data interrupt in incoming data to know whether end >>> of frame achieve or not. >>> - Hw controlled RTS and CTS flow control to reduce SW overhead. >> >>> diff --git >>> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >>> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >> >>> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver. >>> + >>> +Required properties: >>> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart". >> >> One question that isn't addressed here is: >> >> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying >> compatible = "nvidia,tegra20-uart". > > The way it is supposed to work is that the compatible property should > list "nvidia,tegra30-hsuart" first, followed by a fallback name that > refers to the generic 8250 compatibility. Having the 8250.c driver bind > to the more-specific tegra30-hsuart name is wrong. 8250.c binds to nvidia,tegra20-uart, so that aspect is fine. However, the real issue is that we probably want 4 of the 5 ports to use the plain old 8250.c (so as not to use up too many DMA channels), but just 1 of the ports to use the DMA-capable high-performance driver (e.g. the one that a particular board has hooked up to a Bluetooth radio). The only way to do that with DT that I know of would be to specify different subsets of legal compatible values for each UART in the per-board .dts file. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: db8500: set CPUFREQ_CONST_LOOPS
On Mon, Dec 17, 2012 at 10:24:15AM -0800, Stephen Boyd wrote:
> On 12/04/12 02:10, Fabio Baltieri wrote:
> > static struct cpufreq_driver db8500_cpufreq_driver = {
> > - .flags = CPUFREQ_STICKY,
> > + .flags = CPUFREQ_STICKY | CPUFREQ_CONST_LOOPS,
>
> Wouldn't you want to fold this into the previous patch so bisection is
> not broken? Otherwise you have a place where lpj is all screwed up when
> cpufreq mucks with it.
You are basically right... but that's not going to be as screwed up as
it's now, so I'd say that it's not worth the rebase unless the
maintainer says so. :-)
Thanks!
Fabio
--
Fabio Baltieri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: Downgrade mmap_sem before locking or populating on mmap
On Sun, Dec 16, 2012 at 7:29 PM, Michel Lespinasse wrote: > On Sun, Dec 16, 2012 at 10:05 AM, Andy Lutomirski wrote: >> On Sun, Dec 16, 2012 at 4:39 AM, Michel Lespinasse wrote: >>> I think this could be done by extending the mlock work I did as part >>> of v2.6.38-rc1. The commit message for >>> c explains the idea; basically >>> mlock() was split into do_mlock() which just sets the VM_LOCKED flag >>> on vmas as needed, and do_mlock_pages() which goes through a range of >>> addresses and actually populates/mlocks each individual page that is >>> part of a VM_LOCKED vma. >> >> Doesn't this have the same problem? It holds mmap_sem for read for a >> long time, and if another writer comes in then r/w starvation >> prevention will kick in. > > Well, my point is that do_mlock_pages() doesn't need to hold the > mmap_sem read side for a long time. It currently releases it when > faulting a page requires a disk read, and could conceptually release > it more often if needed. I can't find this code. It looks like do_mlock_pages calls __mlock_vma_pages_range, which calls __get_user_pages, which makes its way to __do_fault, which doesn't seem to drop mmap_sem. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts: add checkmaintainers.py
Em 17-12-2012 15:00, Borislav Petkov escreveu: On Mon, Dec 17, 2012 at 07:35:44AM -0800, Joe Perches wrote: Perhaps Cesar can use his script as a starting point to find those pattern invalidating commits or maybe add the capability (or a --strict check) to checkpatch. Or that, I don't have a strict preference. So, yeah, I can see how checkpatch saying: "you've just renamed a file and thusly invalidated a pattern in MAINTAINERS. Pls, consider correcting the pattern" could make sense. And I would even add it to default functionality since the MAINTAINERS patterns are something we want to always have up-to-date, IMO. Good idea, but a standalone MAINTAINERS checker is still useful, to check for things checkpatch did not catch, either because it was not run, or because it did not have enough information. For instance, consider the case of a patch removing the last file in a directory going in via one branch, while a patch adding a file pattern for that same directory goes in via a separate branch. There is no way checkpatch can catch that. As for finding the pattern invalidating commits, it is usually not that hard, a simple "git log -- " or similar usually does the trick, except in the cases where the pattern addition itself was wrong. The hard part can be interpreting it and the surrounding commits to find out the committer's intention, how it should affect the MAINTAINERS entry, and who should get a Cc: of the fix. -- Cesar Eduardo Barros ces...@cesarb.net cesar.bar...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 11:36 AM, Stephen Warren wrote: > On 12/17/2012 05:10 AM, Laxman Dewangan wrote: >> Nvidia's Tegra has multiple uart controller which supports: >> - APB dma based controller fifo read/write. >> - End Of Data interrupt in incoming data to know whether end >> of frame achieve or not. >> - Hw controlled RTS and CTS flow control to reduce SW overhead. > >> diff --git >> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt > >> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver. >> + >> +Required properties: >> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart". > > One question that isn't addressed here is: > > Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying > compatible = "nvidia,tegra20-uart". The way it is supposed to work is that the compatible property should list "nvidia,tegra30-hsuart" first, followed by a fallback name that refers to the generic 8250 compatibility. Having the 8250.c driver bind to the more-specific tegra30-hsuart name is wrong. However, the 8250.c driver doesn't > support the DMA features of this driver. This driver is an alternate > driver for the same HW that allows DMA to be used with it, etc. > > Since DT is supposed to describe the HW, modifying the DT to change the > compatible value in order to select a different driver in Linux doesn't > seem correct, or is it? Is there any kind of precedent for how to select > different drivers for the same HW at run-time? I'd wondered about using > the sysfs bind/unbind "methods" from user-space as the driver selection > mechanism... > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] cpuidle_get_cpu_driver livelocks idle system
On 12/17/2012 08:36 PM, Russ Anderson wrote:
> The 3.7 kernel grinds to a halt on boot of a system with
> 2048 cpus. NMI showed most of the cpus in
> _raw_spin_lock in cpuidle_get_cpu_driver(). (backtrace below)
>
> A quick look at cpuidle_get_cpu_driver() shows the hot lock.
>
> In drivers/cpuidle/driver.c:
>
> /**
> * cpuidle_get_cpu_driver - return the driver tied with a cpu
> */
> struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
> {
> struct cpuidle_driver *drv;
>
> if (!dev)
> return NULL;
>
> spin_lock(_driver_lock);
> drv = __cpuidle_get_cpu_driver(dev->cpu);
> spin_unlock(_driver_lock);
>
> return drv;
> }
>
Hi Russ,
thanks for investigating the problem. You are right, there is a
bottleneck here.
Regarding how is used the cpuidle code, I think it is safe to remove the
locks.
> This change was added in on Nov 14th, 2012.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92
>
> The patch says it adds support for cpus with different characteristics,
> but adds a big global lock. The comment claims "no impact for the other
> platforms if the option is disabled", which leads me to believe the
> spin_lock was added inadvertently. CPU_IDLE_MULTIPLE_DRIVERS is off
> in my config file.
>
> linux$ grep CPU_IDLE_MULTIPLE_DRIVERS .config
> # CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
>
> As more cpus become idle, more cpus fight over the lock until
> the system livelocks on the crushing weight of idle.
>
> The fix may be to move the spin_lock into __cpuidle_get_cpu_driver,
> which has different versions for CONFIG_CPU_IDLE_MULTIPLE_DRIVERS,
> to avoid impacting the disabled case, or get rid of the spin_lock
> all together.
>
>
>
> == UV NMI process trace cpu 12: ==
> CPU 12
> Pid: 0, comm: swapper/12 Tainted: G O 3.7.0.rja-sgi+ #38
> RIP: 0010:[] [] _raw_spin_lock+0x25/0x30
> [...]
> Call Trace:
> [] cpuidle_get_cpu_driver+0x1c/0x30
> [] cpuidle_idle_call+0x7d/0x1b0
> [] cpu_idle+0xdd/0x130
> [] start_secondary+0xc6/0xcc
>
>
--
Facebook |
Twitter |
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
> Nvidia's Tegra has multiple uart controller which supports:
> - APB dma based controller fifo read/write.
> - End Of Data interrupt in incoming data to know whether end
> of frame achieve or not.
> - Hw controlled RTS and CTS flow control to reduce SW overhead.
>
> Add serial driver to use all above feature.
> diff --git a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
> +Required properties:
> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".
I think you want ", or" not just "," there. If both are specified,
"tegra30" should come before "tegra20", so you might want to re-order
that. That said, other bindings say something like
"nvidia,tegra-hsuart" so avoid having to spell out all the
supported Tegra versions.
> diff --git a/drivers/tty/serial/serial_tegra.c
> b/drivers/tty/serial/serial_tegra.c
> +struct tegra_uart_chip_data tegra20_uart_chip_data = {
> + .tx_fifo_full_status= false,
> + .allow_txfifo_reset_fifo_mode = true,
> + .support_clk_src_div= false,
> +};
> +
> +struct tegra_uart_chip_data tegra30_uart_chip_data = {
> + .tx_fifo_full_status= true,
> + .allow_txfifo_reset_fifo_mode = false,
> + .support_clk_src_div= true,
> +};
Nit: Perhaps it'd be nice to move those right before
tegra_uart_of_match[] - i.e. right where they're used.
> +static struct tegra_uart_platform_data *tegra_uart_parse_dt(
> + if (of_get_property(np, "nvidia,enable-modem-interrupt", NULL))
> + pdata->enable_modem_interrupt = 1;
That should use of_property_read_bool().
> +static int __devinit tegra_uart_probe(struct platform_device *pdev)
> + if (pdev->dev.of_node) {
That will always be true these days.
I didn't review the body of the UART implementation since I'm not
familiar with drivers/tty/serial nor too much about our UART HW beyond
basic 8250 usage.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling
On Mon, Dec 17, 2012 at 01:33:14PM -0800, Tejun Heo wrote: > Hello, > > On Mon, Dec 17, 2012 at 04:27:36PM -0500, Vivek Goyal wrote: > > What I do care about is atleast being able to read and understand the > > code easily. Right now, it is hard to understand. I am still struggling > > to wrap my head around it. > > Hmm... I thought it was really simple. Maybe I'm just too familiar > with it. You just walk up the tree multiplying the fraction you have > at each level. It really doesn't get much simpler than that. > > > For example, while adding a group to service tree we calculate > > cfqg->vfaction as follows. > > > > vfr = vfr * pos->leaf_weight / pos->level_weight; > > > > and then > > > > vfr = vfr * pos->weight / parent->level_weight; > > > > cfqg->vfraction = max_t(unsigned, vfr, 1) > > > > If cfqg->vfraction is about cfqg then why should we take into account > > leaf_weight and level_weight. We should be just worried about pos->weight > > and parent->level_weight and that should determine vfaction of cfqg. > > Eh? Then how would it compete with the children cfqgs? You can > consider it as the hidden leaf node competing with the children cfqgs, > right? So, you take the leaf weight and divide it by the total active > weight of all the children (including the hidden leaf node). It isn't > different from the rest of the calculation. It just looks different > because leaf_weight is stored elsewhere and we look down there and > then walke up. The calculation being done is exactly the same one. Again it is coming from multiplexing cfqg and cfqg->task_group. So effectively we are calculating the vfraction of task_group inside cfqg. Once you say cfqg->vfraction, I immediately think of total share of group (including task_group and all children cgroups). May be cfqg->task_group_vfraction (or cfqg->tg_fraction) is a better name. Also descrition says. /* vfraction the fraction of vdisktime that a cfqg is entitled to */ May be we can clarify it that it is share of task_group of cfqg. I guess i am too familiar with how cpu has done it. I think I am getting confused with properties which belong to cfqg and properties which belong to cfqg->task_group. I guess if we prefix fields belong to task_group with somete suitable string, it might become little easier to understand. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] ARM: tegra: Add OF_DEV_AUXDATA for uart driver in board dt
On 12/17/2012 05:08 AM, Laxman Dewangan wrote:
> Add OF_DEV_AUXDATA for high speed uart controller driver for
> Tegra20/Tegra30 board dt files.
> Set the parent clock of uart controller to PLLP.
> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
> b/arch/arm/mach-tegra/board-dt-tegra20.c
> @@ -94,6 +94,11 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata
> = {
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006000, "tegra-uart.0",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006040, "tegra-uart.1",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006200, "tegra-uart.2",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006300, "tegra-uart.3",
> NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-hsuart", 0x70006400, "tegra-uart.4",
> NULL),
Instead, can we simply get the clocks from device tree? Prashant, how
much effort will that be once your clock patches are checked in, or is
it already part of those patches?
> @@ -106,7 +111,10 @@ struct of_dev_auxdata tegra20_auxdata_lookup[]
> __initdata = {
> static __initdata struct tegra_clk_init_table tegra_dt_clk_init_table[] = {
> /* name parent rateenabled */
> { "uarta", "pll_p",21600, true },
> + { "uartb", "pll_p",21600, false },
> + { "uartc", "pll_p",21600, false },
> { "uartd", "pll_p",21600, true },
> + { "uarte", "pll_p",21600, false },
Prashant's clock patches remove this table. Please work with him to work
out how to deal with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] pstore,efi_pstore: Avoid deadlock in non-blocking paths
On Mon, Dec 17, 2012 at 08:56:27PM +, Seiji Aguchi wrote: > Changelog v1 -> v2 > - Erase a logic checking the number of online cpus. > - Create a patchset to fix deadlocking issue in both pstore filesystem and >efi_pstore driver. >- Introduce a function, is_non_blocking_path(), to check if pstore > is in panic and emergency-restart paths (PATCH 1/2) >- Avoid efi_pstore_driver is blocked in non-blocking paths > such as nmi, panic and emergency-restart paths (PATCH 2/2) This patch set seems cleaner. Though it seems most of patch2 should have been in patch1 (except for the efi part). The only nitpick I have is the name 'is_non_blocking_path'. I don't know why, but the name doesn't seem exactly right to me. I was thinking something like 'pstore_cannot_block_path' or something. But it is just a nitpick, so it doesn't matter either way to me. Cheers, Don > > [Issue] > > There are some paths which shouldn't be blocked in kernel, like NMI, panic > case after stopping cpus, > emergency-restart. > > On the other hand, current pstore avoids blocking in a NMI path but it may be > blocked in other paths. > Also, an efi_pstore driver may be blocked in all of those paths because it > simply takes a spin lock > at writing time. > > If they are blocked in those paths, the system will hang up and it has a big > impact for users. > > Here is an example scenario which pstore is blocked in panic path. > > - cpuA grabs psinfo->buf_lock > - cpuB panics and calls smp_send_stop > - smp_send_stop sends IRQ to cpuA >after 1 second, cpuB gives up on cpuA and sends an NMI instead > - cpuA is now in an NMI handler while still holding buf_lock. >And then, cpuB is deadlocked by taking efi_pstore->lock again. > > This case may happen if a firmware has a bug and cpuA is stuck in it. > > [Solution] > > This patchset avoids that pstore and efi_pstore driver are blocked in the > non-blocking paths > like NMI, panic, and emrgency-restart by introducing a function checking if > they are in those paths. > Please see each patch for detailed explanations. > > Seiji Aguchi (2): > [PATCH v2 1/2] pstore: Avoid deadlock in panic and emergency-restart path > [PATCH v2 2/2] efi_pstore: Avoid deadlock in non-blocking paths > > drivers/firmware/efivars.c | 11 ++- > fs/pstore/platform.c | 34 -- > include/linux/pstore.h |6 ++ > 3 files changed, 44 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Btrfs updates
[ sorry, resend. My lbdb autocompleted with an extra r in kernel.org ]
Hi everyone,
My for-linus branch has a big set of fixes and features:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
This was against 3.7, and it has two easy conflicts against Linus'
current head. My -next branch has the resolutions, but Linus wills
surely fix these himself.
In terms of line count, most of the code comes from Stefan, who added
the ability to replace a single drive in place. This is different from
how btrfs normally replaces drives, and is much much much faster.
Josef is plowing through our synchronous write performance. This pull
request does not include the DIO_OWN_WAITING patch that was discussed on
the list, but it has a number of other improvements to cut down our
latencies and CPU time during fsync/O_DIRECT writes.
Miao Xie has a big series of fixes and is spreading out ordered
operations over more CPUs. This improves performance and reduces
contention.
I've put in fixes for error handling around hash collisions. These are
going back to individual stable kernels as I test against them.
Otherwise we have a lot of fixes and cleanups, thanks everyone! raid5/6
is being rebased against the device replacement code. I'll have it
posted this Friday along with a nice series of benchmarks.
Stefan Behrens (33) commits (+3446/-831):
Btrfs: change core code of btrfs to support the device replace operations
(+111/-14)
Btrfs: allow repair code to include target disk when searching mirrors
(+154/-5)
Btrfs: changes to live filesystem are also written to replacement disk
(+49/-1)
Btrfs: introduce GET_READ_MIRRORS functionality for btrfs_map_block()
(+11/-7)
Btrfs: remove the block device pointer from the scrub context struct
(+73/-60)
Btrfs: disallow some operations on the device replace target device
(+54/-18)
Btrfs: disallow mutually exclusive admin operations from user mode (+40/-17)
Btrfs: Pass fs_info to btrfs_num_copies() instead of mapping_tree (+15/-15)
Btrfs: fix BUG() in scrub when first superblock reading gives EIO (+11/-0)
Btrfs: pass fs_info to btrfs_map_block() instead of mapping_tree (+32/-37)
Btrfs: Don't trust the superblock label and simply printk("%s") it (+5/-2)
Btrfs: don't allow degraded mount if too many devices are missing (+16/-0)
Btrfs: optionally avoid reads from device replace source drive (+35/-11)
Btrfs: fix race in check-integrity caused by usage of bitfield (+1/-1)
Btrfs: in scrub repair code, optimize the reading of mirrors (+12/-23)
Btrfs: add code to scrub to copy read data to another disk (+851/-73)
Btrfs: in scrub repair code, simplify alloc error handling (+26/-35)
Btrfs: enhance btrfs structures for device replace support (+44/-0)
Btrfs: make the scrub page array dynamically allocated (+121/-74)
Btrfs: increase BTRFS_MAX_MIRRORS by one for dev replace (+1/-1)
Btrfs: handle errors from btrfs_map_bio() everywhere (+65/-33)
Btrfs: avoid risk of a deadlock in btrfs_handle_error (+10/-1)
Btrfs: fix a scrub regression in case of write errors (+2/-1)
Btrfs: add new sources for device replace code (+1069/-1)
Btrfs: move some common code into a subfunction (+50/-43)
Btrfs: introduce a btrfs_dev_replace_item type (+69/-0)
Btrfs: add btrfs_scratch_superblock() function (+19/-0)
Btrfs: cleanup scrub bio and worker wait code (+71/-35)
Btrfs: fix a build warning for an unused label (+0/-1)
Btrfs: add support for device replace ioctls (+52/-3)
Btrfs: rename the scrub context structure (+253/-253)
Btrfs: add two more find_device() methods (+64/-0)
Btrfs: pass fs_info instead of root (+60/-66)
Miao Xie (32) commits (+840/-471):
Btrfs: fix missing reserved space release in error path of delalloc
reservation (+7/-0)
Btrfs: fix off-by-one error of the same page check in btrfs_punch_hole()
(+2/-2)
Btrfs: fix unprotected extent map operation when logging file extents
(+2/-0)
Btrfs: fix unnecessary while loop when search the free space, cache
(+10/-20)
Btrfs: fix off-by-one error of the reserved size of btrfs_allocate() (+2/-2)
Btrfs: fix joining the same transaction handler more than 2 times (+48/-30)
Btrfs: fix missing log when BTRFS_INODE_NEEDS_FULL_SYNC is set (+4/-1)
Btrfs: pass root object into btrfs_ioctl_{start, wait}_sync() (+6/-6)
Btrfs: get write access when setting the default subvolume (+28/-12)
Btrfs: make ordered operations be handled by multi-task (+45/-21)
Btrfs: fix wrong return value of btrfs_wait_for_commit() (+8/-7)
Btrfs: don't start a new transaction when starting sync (+18/-9)
Btrfs: fix missing flush when committing a transaction (+47/-35)
Btrfs: fix wrong return value of btrfs_truncate_page() (+1/-2)
Btrfs: make delalloc inodes be flushed by multi-task (+103/-8)
Btrfs: use existing align macros in btrfs_allocate() (+4/-4)
Btrfs: make
Re: [PATCH 2/4] ARM: tegra: add connection name for uart clock table
On 12/17/2012 05:08 AM, Laxman Dewangan wrote: > Add connection name "uart-clk" for the uart clock information. Does the UART receive more than one clock, so that it actually cares what the clock connection name is? If not, can we just drop this patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: tegra30: Add support for Uart clock source divider as 15.1
On 12/17/2012 05:08 AM, Laxman Dewangan wrote: > Tegra20 uart clock source have the 15.1 clock divider in place of That says Tegra20, but ... > 7.1. Add support for 15.1 clock divider and change the uart clock divider > flag to DIV_U151. > arch/arm/mach-tegra/clock.h |3 +- > arch/arm/mach-tegra/tegra30_clocks.c | 70 ++-- > arch/arm/mach-tegra/tegra30_clocks_data.c | 10 ++-- ... the patch only modifies Tegra30. Do both Tegra20 and Tegra30 have this feature; should both clock drivers be updated? BTW, Prashant is reworking the Tegra clock support to be modular, rather than having a single monolithic "Tegra clock" type, and also moving the code to drivers/clk. This patch will conflict signifcantly with that. Please work with him to integrate this patch into his rework series, either before or after his changes, and have him include the patch when he posts his series. You'll also need to think about whether/how your and his series depend on each-other. ... but: Is this a pure bug-fix? If so, I guess this patch should be applied before Prashant's patches, and this patch also Cc: stable? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] can: add tx/rx LED trigger support
On Mon, Dec 17, 2012 at 09:20:57PM +0100, "Bernd Krumböck" wrote: > > If you think it's useful for USB controller, just tell me or modify the > > driver by yourself! As you see the patch is really easy. > > At least it is useful for the usb_8dev driver. I'll write a patch. > > Photo of the device: > http://www.8devices.com/product/2/usb2can Sure that it's needed? That status LED is probably controlled directly by the firmware itself. Anyway I think it makes sense to support all the mainline drivers and I'm really happy if you test the patch on your hardware! My only suggestion is to keep the LED support on a separate patch from the "add driver" one. Cheers, Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ODROID-X: dts: Add mshc node for ODROID-X board
Hi Dongjin,
On Tuesday 18 of December 2012 04:55:07 Dongjin Kim wrote:
> Adding the device node to support eMMC storage on SDCARD4 ports,
> controlled by Mobile Storage Host Controller.
>
> Signed-off-by: Dongjin Kim
> ---
> arch/arm/boot/dts/exynos4412-odroidx.dts | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
> b/arch/arm/boot/dts/exynos4412-odroidx.dts index 3943011..fbd0b51
> 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidx.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
> @@ -73,4 +73,25 @@
> linux,default-trigger = "mmc0";
> };
> };
> +
> + mshc@1255 {
> + num-slots = <1>;
> + supports-highspeed;
> + broken-cd;
> + fifo-depth = <0x80>;
> + card-detect-delay = <200>;
> + samsung,dw-mshc-ciu-div = <3>;
> + samsung,dw-mshc-sdr-timing = <2 3 3>;
> + samsung,dw-mshc-ddr-timing = <1 2 3>;
> +
> + slot@0 {
> + reg = <0>;
> + bus-width = <8>;
> + gpios = < 0 3>, < 1 3>,
> + < 3 3>, < 4 3>,
> + < 5 3>, < 6 3>,
> + < 3 4>, < 4 4>,
> + < 5 4>, < 6 4>;
What is the gpios property for in this node? Pin configuration using
legacy GPIO bindings is not supported anymore on Exynos4. Pin control
bindings must be used.
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] w1_therm:Retries:remove old code add CRC
w1_therm includes some obsolete code to detect bad_roms, this is no
longer relevant.
The retry code is only used for this bad_rom test, however there is a
CRC check that detects a bad read, but does not trigger a retry. This
patch removes all the bad_rom code and uses the CRC check to trigger
retries.
Patch is against Raspberry 3.2.27 ( my test hardware) but has also been
tested against 3.7.
David Stevenson david at avoncliff.com
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 016dd7d..8166075 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -45,10 +45,6 @@ MODULE_DESCRIPTION("Driver for 1-wire Dallas network
protocol, temperature famil
static int w1_strong_pullup = 1;
module_param_named(strong_pullup, w1_strong_pullup, int, 0);
-static u8 bad_roms[][9] = {
- {0xaa, 0x00, 0x4b, 0x46, 0xff, 0xff, 0x0c,
0x10, 0x87},
- {}
- };
static ssize_t w1_therm_read(struct device *device,
struct device_attribute *attr, char *buf);
@@ -159,16 +155,6 @@ static inline int w1_convert_temp(u8 rom[9], u8 fid)
return 0;
}
-static int w1_therm_check_rom(u8 rom[9])
-{
- int i;
-
- for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc0 on xen-unstable: RCU Stall during boot as dom0 kernel after IOAPIC
Monday, December 17, 2012, 10:12:40 PM, you wrote:
> On Mon, Dec 17, 2012 at 03:46:34PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 17, 2012 at 09:32:17PM +0100, Sander Eikelenboom wrote:
>> >
>> > Sunday, December 16, 2012, 6:38:24 PM, you wrote:
>> >
>> > > On Fri, Dec 14, 2012 at 04:55:57PM +0100, Sander Eikelenboom wrote:
>> > >> Hi Konrad,
>> > >>
>> > >> I just tried to boot a 3.8.0-rc0 kernel (last commit:
>> > >> 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with
>> > >> current xen-unstable.
>> >
>> > > Yeah, saw it over the Dec 11->Dec 12 merges and was out on
>> > > vacation during that time (just got back).
>> >
>> > > Did you by any chance try to do a git bisect to narrow down
>> > > which merge it was?
>> >
>> > Hi Konrad,
>>
>> Hey Sander,
>>
>> Thank you for doing the bisection.
>>
>> Fenghua - any ideas what might be amiss in the Xen subsystem?
>> I hadn't looked at the patchset of the CPU0 offlining/onlining
>> so I am not completly up to speed on the particulars of the patches.
>> > 30106c174311b8cfaaa3186c7f6f9c36c62d17da is the first bad commit
>> > commit 30106c174311b8cfaaa3186c7f6f9c36c62d17da
>> > Author: Fenghua Yu
>> > Date: Tue Nov 13 11:32:41 2012 -0800
>> >
>> > x86, hotplug: Support functions for CPU0 online/offline
>> >
>> > Add smp_store_boot_cpu_info() to store cpu info for BSP during boot
>> > time.
>> >
>> > Now smp_store_cpu_info() stores cpu info for bringing up BSP or AP
>> > after
>> > it's offline.
>> >
>> > Continue to online CPU0 in native_cpu_up().
>> >
>> > Continue to offline CPU0 in native_cpu_disable().
>> >
>> > Signed-off-by: Fenghua Yu
>> > Link:
>> > http://lkml.kernel.org/r/1352835171-3958-5-git-send-email-fenghua...@intel.com
>> > Signed-off-by: H. Peter Anvin
>> >
> This patch:
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 353c50f..4f7d259 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -254,7 +254,7 @@ static void __init xen_smp_prepare_cpus(unsigned int
> max_cpus)
> }
> xen_init_lock_cpu(0);
>
> - smp_store_cpu_info(0);
> + smp_store_boot_cpu_info();
> cpu_data(0).x86_max_cores = 1;
>
> for_each_possible_cpu(i) {
> Would do the corresponding change in the Xen subsystem that the above
> mentioned commit did. Perhaps that is all that is needed? I am going to
> be able to test this and look in more details tomorrow.
Seems like it, don't know if there are other things still lurking, but with
your patch it boots again as dom0 :-)
Thx !
--
Sander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 05:10 AM, Laxman Dewangan wrote: > Nvidia's Tegra has multiple uart controller which supports: > - APB dma based controller fifo read/write. > - End Of Data interrupt in incoming data to know whether end > of frame achieve or not. > - Hw controlled RTS and CTS flow control to reduce SW overhead. > diff --git a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt > b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt > +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver. > + > +Required properties: > +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart". One question that isn't addressed here is: Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying compatible = "nvidia,tegra20-uart". However, the 8250.c driver doesn't support the DMA features of this driver. This driver is an alternate driver for the same HW that allows DMA to be used with it, etc. Since DT is supposed to describe the HW, modifying the DT to change the compatible value in order to select a different driver in Linux doesn't seem correct, or is it? Is there any kind of precedent for how to select different drivers for the same HW at run-time? I'd wondered about using the sysfs bind/unbind "methods" from user-space as the driver selection mechanism... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 0/6 v10] gpio: Add block GPIO
On 17/12/12 20:47, Wolfgang Grandegger wrote:
> On 12/17/2012 07:02 PM, Roland Stigge wrote:
>> On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
>>> /* Do synchronous data output with a single write access */
>>> __raw_writel(~mask, pio + PIO_OWDR);
>>> __raw_writel(mask, pio + PIO_OWER);
>>> __raw_writel(val, pio + PIO_ODSR);
>>>
>>> For caching we would need a storage. Not sure if it's worth compared to
>>> a context switch into the kernel.
>>
>> Block GPIO is not only for you in userspace. ;-) You can also implement
>> efficient n-bit bus I/O in kernel drivers, n-bit-banging. :-) So not
>> always context switches involved.
>
> OK, what do you think about the following untested patch:
Looks good!
Why "untested"? ;-)
Thanks,
Roland
>>From b44cad16cbbca84715dffd4cb5268497216add25 Mon Sep 17 00:00:00 2001
> From: Wolfgang Grandegger
> Date: Mon, 3 Dec 2012 08:31:55 +0100
> Subject: [PATCH 1/2] gpio: add GPIO block callback functions for AT91
>
> Signed-off-by: Wolfgang Grandegger
> ---
> arch/arm/mach-at91/gpio.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
> index be42cf0..cf6bd45 100644
> --- a/arch/arm/mach-at91/gpio.c
> +++ b/arch/arm/mach-at91/gpio.c
> @@ -42,13 +42,16 @@ struct at91_gpio_chip {
> void __iomem*regbase; /* PIO bank virtual address */
> struct clk *clock; /* associated clock */
> struct irq_domain *domain;/* associated irq domain */
> + unsigned long mask_shadow;/* synchronous data output */
> };
>
> #define to_at91_gpio_chip(c) container_of(c, struct at91_gpio_chip, chip)
>
> static void at91_gpiolib_dbg_show(struct seq_file *s, struct gpio_chip
> *chip);
> static void at91_gpiolib_set(struct gpio_chip *chip, unsigned offset, int
> val);
> +static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
> mask, unsigned long val);
> static int at91_gpiolib_get(struct gpio_chip *chip, unsigned offset);
> +static unsigned long at91_gpiolib_get_block(struct gpio_chip *chip, unsigned
> long mask);
> static int at91_gpiolib_direction_output(struct gpio_chip *chip,
>unsigned offset, int val);
> static int at91_gpiolib_direction_input(struct gpio_chip *chip,
> @@ -62,7 +65,9 @@ static int at91_gpiolib_to_irq(struct gpio_chip *chip,
> unsigned offset);
> .direction_input = at91_gpiolib_direction_input, \
> .direction_output = at91_gpiolib_direction_output, \
> .get = at91_gpiolib_get, \
> + .get_block= at91_gpiolib_get_block, \
> .set = at91_gpiolib_set, \
> + .set_block= at91_gpiolib_set_block, \
> .dbg_show = at91_gpiolib_dbg_show, \
> .to_irq = at91_gpiolib_to_irq,\
> .ngpio= nr_gpio,\
> @@ -896,6 +901,16 @@ static int at91_gpiolib_get(struct gpio_chip *chip,
> unsigned offset)
> return (pdsr & mask) != 0;
> }
>
> +static unsigned long at91_gpiolib_get_block(struct gpio_chip *chip, unsigned
> long mask)
> +{
> + struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
> + void __iomem *pio = at91_gpio->regbase;
> + u32 pdsr;
> +
> + pdsr = __raw_readl(pio + PIO_PDSR);
> + return pdsr & mask;
> +}
> +
> static void at91_gpiolib_set(struct gpio_chip *chip, unsigned offset, int
> val)
> {
> struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
> @@ -905,6 +920,20 @@ static void at91_gpiolib_set(struct gpio_chip *chip,
> unsigned offset, int val)
> __raw_writel(mask, pio + (val ? PIO_SODR : PIO_CODR));
> }
>
> +static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
> mask, unsigned long val)
> +{
> + struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
> + void __iomem *pio = at91_gpio->regbase;
> +
> + /* Do synchronous data output with a single write access */
> + if (mask != at91_gpio->mask_shadow) {
> + at91_gpio->mask_shadow = mask;
> + __raw_writel(~mask, pio + PIO_OWDR);
> + __raw_writel(mask, pio + PIO_OWER);
> + }
> + __raw_writel(val, pio + PIO_ODSR);
> +}
> +
> static void at91_gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip)
> {
> int i;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling
Hello, On Mon, Dec 17, 2012 at 04:27:36PM -0500, Vivek Goyal wrote: > What I do care about is atleast being able to read and understand the > code easily. Right now, it is hard to understand. I am still struggling > to wrap my head around it. Hmm... I thought it was really simple. Maybe I'm just too familiar with it. You just walk up the tree multiplying the fraction you have at each level. It really doesn't get much simpler than that. > For example, while adding a group to service tree we calculate > cfqg->vfaction as follows. > > vfr = vfr * pos->leaf_weight / pos->level_weight; > > and then > > vfr = vfr * pos->weight / parent->level_weight; > > cfqg->vfraction = max_t(unsigned, vfr, 1) > > If cfqg->vfraction is about cfqg then why should we take into account > leaf_weight and level_weight. We should be just worried about pos->weight > and parent->level_weight and that should determine vfaction of cfqg. Eh? Then how would it compete with the children cfqgs? You can consider it as the hidden leaf node competing with the children cfqgs, right? So, you take the leaf weight and divide it by the total active weight of all the children (including the hidden leaf node). It isn't different from the rest of the calculation. It just looks different because leaf_weight is stored elsewhere and we look down there and then walke up. The calculation being done is exactly the same one. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 10:10 AM, Grant Likely wrote:
> On Mon, 17 Dec 2012 17:40:49 +0530, Laxman Dewangan
> wrote:
>> Nvidia's Tegra has multiple uart controller which supports:
>> - APB dma based controller fifo read/write.
>> - End Of Data interrupt in incoming data to know whether end
>> of frame achieve or not.
>> - Hw controlled RTS and CTS flow control to reduce SW overhead.
>> +static int __devinit tegra_uart_probe(struct platform_device *pdev)
>> +{
>> +struct tegra_uart_port *tup;
>> +struct uart_port *u;
>> +struct tegra_uart_platform_data *pdata = pdev->dev.platform_data;
>
> Since this is a new driver, and all new board support will use device
> tree, when would this platform_data pointer get set? Can you drop the
> platform_data support code entirely?
Aren't we still supposed to support platform data so that it can
override what's in DT in order to fix up bad DTs? Or, has that
requirement been dropped. If it has, we can drop a bunch of code from a
variety of Tegra-specific drivers, I expect.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On an (outdated) laptop the radeon driver (almost always) prints, during
the first resume of each session:
[drm] crtc 1 is connected to a TV
This message is a bit puzzling as, as far as I know, no TV has ever
been connected to this laptop. Anyhow, before v3.5, if that happened the
radeon driver then printed an error during all following resumes:
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
(-35 is -EDEADLK.) But the resume would succeed and the driver seemed to
run without too much trouble. From v3.5 onwards things changed. If the
(puzzling) message about crtc 1 was printed on first resume the laptop
would simply hang on second resume. Only a manual power off would then
be possible. In that case nothing of interest would be found in the
(truncated) logs. And, most annoyingly, the hang would never happen if
the laptop was booted with, say, "console=ttyS0,115200n8" added to the
kernel command line.
I bisected the hang to commit 6c6f478370eccfbfafbdc6fc55c0def03e58f124
("drm/radeon: rework recursive gpu reset handling"), which was added in
the v3.5 release cycle. After discovering that and poking at the driver
it turned out that this hang is triggered by radeon_cs_handle_lockup()
returning -EAGAIN after successfully resetting the gpu. Simply returning
0 makes the hang disappear (and makes the drm error reappear).
Nothing in the code or the commit explanation clarifies why -EAGAIN
should be returned on successful gpu reset. So I suggest
radeon_cs_handle_lockup() simply returns what radeon_gpu_reset()
returns, eg 0 (on success) or a negative error code (on failure).
Signed-off-by: Paul Bolle
---
0) This exact patch is untested (but I run something comparable).
1) Sent as an RFC because I do not understand why this laptop (almost
always) prints the "crtc 1" message on first resume. Note that another
workaround for this hang is simply booting with "radeon.tv=0".
2) Also sent as an RFC because I have no idea whatsoever why returning
-EAGAIN will hang the machine. I guess it's returned to userland by
radeon_cs_ioctl(). What code uses that ioctl? And what does that code do
on -EAGAIN that hangs this laptop?
3) A third reason to send this as an RFC is that I also have no idea why
this hang doesn't happen when booting with "console=ttyS0,115200n8" or
even "console=tty0"! But I guess I'm now allowed to call this hang a
Heisenbug.
drivers/gpu/drm/radeon/radeon_cs.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 41672cc..a302c00 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -486,11 +486,8 @@ out:
static int radeon_cs_handle_lockup(struct radeon_device *rdev, int r)
{
- if (r == -EDEADLK) {
+ if (r == -EDEADLK)
r = radeon_gpu_reset(rdev);
- if (!r)
- r = -EAGAIN;
- }
return r;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] NTP: Add a CONFIG_RTC_SYSTOHC configuration
The purpose of this option is to allow ARM/etc systems that rely on the
class RTC subsystem to have the same kind of automatic NTP based
synchronization that we have on PC platforms. Today ARM does not
implement update_persistent_clock and makes extensive use of the class
RTC system.
When enabled CONFIG_RTC_SYSTOHC will provide a generic
rtc_update_persistent_clock that stores the current time in the RTC and
is intended complement the existing CONFIG_RTC_HCTOSYS option that loads
the RTC at boot.
Like with RTC_HCTOSYS the platform's update_persistent_clock is used
first, if it works. Platforms with mixed class RTC and non-RTC drivers
need to return ENODEV when class RTC should be used. Such an update for
PPC is included in this patch.
Long term, implementations of update_persistent_clock should migrate to
proper class RTC drivers and use CONFIG_RTC_SYSTOHC instead.
Tested on ARM kirkwood and PPC405
Signed-off-by: Jason Gunthorpe
---
arch/powerpc/kernel/time.c |2 +-
drivers/rtc/Kconfig| 10 +-
drivers/rtc/Makefile |1 +
drivers/rtc/systohc.c | 44
include/linux/rtc.h|1 +
kernel/time/ntp.c | 16
6 files changed, 68 insertions(+), 6 deletions(-)
create mode 100644 drivers/rtc/systohc.c
v3 changes:
- Test menuconfig, reorder options to look better, fix kconfig
RTC_HCTOSYS_DEVICE to be 'or' not 'and'
- Change the function name to rtc_set_ntp_time to avoid confusing
this api with the distinct *_persistant_clock stuff
- Fix typo in the ENODEV test to be || not &&
- Fully retest on ARM+PPC
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index ce4cb77..bc844a8 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -667,7 +667,7 @@ int update_persistent_clock(struct timespec now)
struct rtc_time tm;
if (!ppc_md.set_rtc_time)
- return 0;
+ return -ENODEV;
to_tm(now.tv_sec + 1 + timezone_offset, );
tm.tm_year -= 1900;
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..b377e96 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -25,9 +25,17 @@ config RTC_HCTOSYS
the value read from a specified RTC device. This is useful to avoid
unnecessary fsck runs at boot time, and to network better.
+config RTC_SYSTOHC
+ bool "Set the RTC time based on NTP synchronization"
+ default y
+ help
+ If you say yes here, the system time (wall clock) will be stored
+ in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11
+ minutes if userspace reports synchronized NTP status.
+
config RTC_HCTOSYS_DEVICE
string "RTC used to set the system time"
- depends on RTC_HCTOSYS = y
+ depends on RTC_HCTOSYS = y || RTC_SYSTOHC = y
default "rtc0"
help
The RTC device that will be used to (re)initialize the system
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56297f0..69d11f1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -6,6 +6,7 @@ ccflags-$(CONFIG_RTC_DEBUG) := -DDEBUG
obj-$(CONFIG_RTC_LIB) += rtc-lib.o
obj-$(CONFIG_RTC_HCTOSYS) += hctosys.o
+obj-$(CONFIG_RTC_SYSTOHC) += systohc.o
obj-$(CONFIG_RTC_CLASS)+= rtc-core.o
rtc-core-y := class.o interface.o
diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
new file mode 100644
index 000..bf3e242
--- /dev/null
+++ b/drivers/rtc/systohc.c
@@ -0,0 +1,44 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include
+#include
+
+/**
+ * rtc_set_ntp_time - Save NTP synchronized time to the RTC
+ * @now: Current time of day
+ *
+ * Replacement for the NTP platform function update_persistent_clock
+ * that stores time for later retrieval by rtc_hctosys.
+ *
+ * Returns 0 on successful RTC update, -ENODEV if a RTC update is not
+ * possible at all, and various other -errno for specific temporary failure
+ * cases.
+ *
+ * If temporary failure is indicated the caller should try again 'soon'
+ */
+int rtc_set_ntp_time(struct timespec now)
+{
+ struct rtc_device *rtc;
+ struct rtc_time tm;
+ int err = -ENODEV;
+
+ if (now.tv_nsec < (NSEC_PER_SEC >> 1))
+ rtc_time_to_tm(now.tv_sec, );
+ else
+ rtc_time_to_tm(now.tv_sec + 1, );
+
+ rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
+ if (rtc) {
+ /* rtc_hctosys exclusively uses UTC, so we call set_time here,
+* not set_mmss. */
+ if (rtc->ops && (rtc->ops->set_time || rtc->ops->set_mmss))
+ err = rtc_set_time(rtc, );
+ rtc_class_close(rtc);
+ }
+
+ return
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 08:24 AM, Rob Herring wrote: > On 12/17/2012 06:10 AM, Laxman Dewangan wrote: >> Nvidia's Tegra has multiple uart controller which supports: >> - APB dma based controller fifo read/write. >> - End Of Data interrupt in incoming data to know whether end >> of frame achieve or not. >> - Hw controlled RTS and CTS flow control to reduce SW overhead. >> >> Add serial driver to use all above feature. >> >> Signed-off-by: Laxman Dewangan >> --- >> .../bindings/serial/nvidia,serial-tegra.txt| 26 + > > Can we have a name without a comma. If serial-tegra is specific enough > for the kernel, then it is for the binding doc too. I would vastly prefer that the binding doc filenames use the compatible value exactly. All (or as many as possible) of the other Tegra bindings do this, and I think it's good style. >> diff --git >> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >> +- nvidia,dma-request-selector : The Tegra DMA controller's phandle and >> + request selector for this UART controller. > > This should use the generic DMA binding although I'm not sure if that > made it into 3.8. It didn't as far as I can tell, even though I think someone said it should... Will it make 3.9? As a general rule, I'd like to move forward on drivers and then refactor this aspect once the generic API/binding is finalized and implemented. (I couldn't find any more comments of yours below, but since the whole patch was quoted, it was difficult to tell) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling
On Mon, Dec 17, 2012 at 01:17:38PM -0800, Tejun Heo wrote: > Hello, > > On Mon, Dec 17, 2012 at 03:53:18PM -0500, Vivek Goyal wrote: > > On Fri, Dec 14, 2012 at 02:41:20PM -0800, Tejun Heo wrote: > > > Currently, cfqg charges are scaled directly according to cfqg->weight. > > > Regardless of the number of active cfqgs or the amount of active > > > weights, a given weight value always scales charge the same way. This > > > works fine as long as all cfqgs are treated equally regardless of > > > their positions in the hierarchy, which is what cfq currently > > > implements. It can't work in hierarchical settings because the > > > interpretation of a given weight value depends on where the weight is > > > located in the hierarchy. > > > > I did not understand this. Why the current scheme will not work with > > hierarchy? > > Because the meaning of a weight changes depending on where the weight > exists in the hierarchy? > > > While we calculate the vdisktime, this is calculated with the help > > of CFQ_DEFAULT_WEIGHT and cfqg->weight. So we scale used time slice > > in proportion to CFQ_DEFAULT_WEIGTH/cfqg->weight. So higher the weight > > lesser the charge and cfqg gets scheduled again faster and lower the > > weight, higher the vdisktime and cfqg gets scheduled less frequently. > > > > As every cfqg does the same thing on service tree, they automatically > > get fair share w.r.t their weight. > > > > And this mechanism should not be impacted by the hierarchy because we > > have a separate service tree at separate level. This will not work > > only if you come up with one compressed tree and then weights will > > have to be adjusted. If we have a separate service tree in each group > > then it should work just fine. > > Why would you create N service trees when you can almost trivially use > one by calcualting the effective weight? You would have to be > adjusting all trees above whenever something changes in a child. One of the reasons I can think is accuracy. If a task/group is added to a service tree, it mostly does not change the fraction of parent and does not change the fraction of parent's sibling. By making everything flat any addition/removal of an entity changes fraction of everything on the tree. Not that I am bothered about it because we do not focus that strictly on fairness. So I would not care about it. What I do care about is atleast being able to read and understand the code easily. Right now, it is hard to understand. I am still struggling to wrap my head around it. For example, while adding a group to service tree we calculate cfqg->vfaction as follows. vfr = vfr * pos->leaf_weight / pos->level_weight; and then vfr = vfr * pos->weight / parent->level_weight; cfqg->vfraction = max_t(unsigned, vfr, 1) If cfqg->vfraction is about cfqg then why should we take into account leaf_weight and level_weight. We should be just worried about pos->weight and parent->level_weight and that should determine vfaction of cfqg. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/12] cfq-iosched: implement cfq_group->nr_active and ->level_weight
On Mon, Dec 17, 2012 at 04:18:43PM -0500, Vivek Goyal wrote: > > > I think confusion happens because we are overloading the definition of > > > cfqg. It is competing with its siblings at the same time it is competing > > > against its child groups (on behalf of its children tasks). > > > > While I agree that part is a bit tricky, I can't think of a much > > better way to describe it. Any better ideas? > > Can we call it cfqg->children_weight insted of cfqg->level_weight. Hmmm... yeah, why not? I'll rename it. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/12] cfq-iosched: implement cfq_group->nr_active and ->level_weight
On Mon, Dec 17, 2012 at 01:15:17PM -0800, Tejun Heo wrote: > Hello, Vivek. > > On Mon, Dec 17, 2012 at 03:46:09PM -0500, Vivek Goyal wrote: > > On Fri, Dec 14, 2012 at 02:41:19PM -0800, Tejun Heo wrote: > > > To prepare for blkcg hierarchy support, add cfqg->nr_active and > > > ->level_weight. cfqg->nr_active counts the number of active cfqgs at > > > the cfqg's level and ->level_weight is sum of weights of those cfqgs. > > > The level covers itself (cfqg->leaf_weight) and immediate children. > > > > This notion of level is really confusing. If one says "at cfqg's level" > > I immediately associate with cfqg's siblings and not with cfqg's children. > > We can explicitly say at children's level but I think it should be > enough to explain it clearly in the comment where the field is > defined. > > > I think confusion happens because we are overloading the definition of > > cfqg. It is competing with its siblings at the same time it is competing > > against its child groups (on behalf of its children tasks). > > While I agree that part is a bit tricky, I can't think of a much > better way to describe it. Any better ideas? Can we call it cfqg->children_weight insted of cfqg->level_weight. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, Dec 17, 2012 at 02:07:59PM -0700, Stephen Warren wrote: > On 12/13/2012 11:59 PM, Venu Byravarasu wrote: > > As Tegra USB host driver is using instance number for resetting > > PORT0 twice, adding a new DT property for handling this. > > Alan, Greg, Felip,e > > This series looks fine to me. > > I'd like to take all the Tegra-related USB patches through the Tegra > tree for 3.9 if possible (so I'm looking for your acks here). I believe > Venu plans to significantly clean up the EHCI/PHY driver split for > Tegra, rework the drivers, and add support for Tegra30 in addition to > Tegra20. Some of this requires changes to some Tegra board files and > device trees to maintain "git bisect" I don't know for sure yet, but I > believe that rework may also end up conflicting with other clock-related > rework that will show up for Tegra in 3.9. Are you OK with this? I'll > certainly look for your review/acks on the patches before picking them > up though. You can't pick anything up for 3.9 until after 3.8-rc1 is out, according to the rules of linux-next, so please wait until that kernel is out before doing anything. Given the timing of 3.8-rc1, and my current vacation schedule, I'm not going to be able to do _any_ code review for the rest of the year, sorry. After that, I'll be glad to review this. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend][PATCH] PM: Move disabling/enabling runtime PM to late suspend/early resume
On 16 December 2012 16:29, Alan Stern wrote: > On Sun, 16 Dec 2012, Rafael J. Wysocki wrote: > >> On Saturday, December 15, 2012 10:16:29 PM Jiri Kosina wrote: >> > On Sat, 15 Dec 2012, Rafael J. Wysocki wrote: >> > >> > > From: Rafael J. Wysocki >> > > >> > > Currently, the PM core disables runtime PM for all devices right >> > > after executing subsystem/driver .suspend() callbacks for them >> > > and re-enables it right before executing subsystem/driver .resume() >> > > callbacks for them. This may lead to problems when there are >> > > two devices such that the .suspend() callback executed for one of >> > > them depends on runtime PM working for the other. In that case, >> > > if runtime PM has already been disabled for the second device, >> > > the first one's .suspend() won't work correctly (and analogously >> > > for resume). >> > > >> > > To make those issues go away, make the PM core disable runtime PM >> > > for devices right before executing subsystem/driver .suspend_late() >> > > callbacks for them and enable runtime PM for them right after >> > > executing subsystem/driver .resume_early() callbacks for them. This >> > > way the potential conflitcs between .suspend_late()/.resume_early() >> > > and their runtime PM counterparts are still prevented from happening, >> > > but the subtle ordering issues related to disabling/enabling runtime >> > > PM for devices during system suspend/resume are much easier to avoid. >> > > >> > > Reported-and-tested-by: Jan-Matthias Braun >> > > Signed-off-by: Rafael J. Wysocki >> > >> > Hi Rafael, >> > >> > just curious what is the reason for resend? Do you want to gather more >> > Acks before pushing this upstream? >> >> Well, I thought that some people might actually look at it when they found it >> again in their mailboxes. :-) > > I did look at it the first time it appeared. It seemed to be okay, but > I haven't tried any testing. > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I believe this should work fine for ux500 platforms, so: Reviewed-by: Ulf Hansson Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling
Hello, On Mon, Dec 17, 2012 at 03:53:18PM -0500, Vivek Goyal wrote: > On Fri, Dec 14, 2012 at 02:41:20PM -0800, Tejun Heo wrote: > > Currently, cfqg charges are scaled directly according to cfqg->weight. > > Regardless of the number of active cfqgs or the amount of active > > weights, a given weight value always scales charge the same way. This > > works fine as long as all cfqgs are treated equally regardless of > > their positions in the hierarchy, which is what cfq currently > > implements. It can't work in hierarchical settings because the > > interpretation of a given weight value depends on where the weight is > > located in the hierarchy. > > I did not understand this. Why the current scheme will not work with > hierarchy? Because the meaning of a weight changes depending on where the weight exists in the hierarchy? > While we calculate the vdisktime, this is calculated with the help > of CFQ_DEFAULT_WEIGHT and cfqg->weight. So we scale used time slice > in proportion to CFQ_DEFAULT_WEIGTH/cfqg->weight. So higher the weight > lesser the charge and cfqg gets scheduled again faster and lower the > weight, higher the vdisktime and cfqg gets scheduled less frequently. > > As every cfqg does the same thing on service tree, they automatically > get fair share w.r.t their weight. > > And this mechanism should not be impacted by the hierarchy because we > have a separate service tree at separate level. This will not work > only if you come up with one compressed tree and then weights will > have to be adjusted. If we have a separate service tree in each group > then it should work just fine. Why would you create N service trees when you can almost trivially use one by calcualting the effective weight? You would have to be adjusting all trees above whenever something changes in a child. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/12] cfq-iosched: implement cfq_group->nr_active and ->level_weight
Hello, Vivek. On Mon, Dec 17, 2012 at 03:46:09PM -0500, Vivek Goyal wrote: > On Fri, Dec 14, 2012 at 02:41:19PM -0800, Tejun Heo wrote: > > To prepare for blkcg hierarchy support, add cfqg->nr_active and > > ->level_weight. cfqg->nr_active counts the number of active cfqgs at > > the cfqg's level and ->level_weight is sum of weights of those cfqgs. > > The level covers itself (cfqg->leaf_weight) and immediate children. > > This notion of level is really confusing. If one says "at cfqg's level" > I immediately associate with cfqg's siblings and not with cfqg's children. We can explicitly say at children's level but I think it should be enough to explain it clearly in the comment where the field is defined. > I think confusion happens because we are overloading the definition of > cfqg. It is competing with its siblings at the same time it is competing > against its child groups (on behalf of its children tasks). While I agree that part is a bit tricky, I can't think of a much better way to describe it. Any better ideas? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ipmi: add new kernel options to prevent automatic ipmi init
On 12/14/2012 12:02 PM, Corey Minyard wrote: >On 12/14/2012 10:25 AM, Evans, Robert wrote: >> Corey, >> >> Thanks for the thoughtful reply. Below I respond in detail to >> these three points. >> >> 1) Why building a variant kernel with ipmi_si as a module is not >> feasible. >> >> 2) User mode access to IPMI on Stratus systems (e.g. ipmitool). >> >> 3) ipmi_si hot removal seems to not work as needed. >> >> Stratus might be able to use the hot removal option instead of the >> proposed patch if hot removal can remove all interfaces from usage >> by ipmi_si. Our testing of this option was not successful as >> shown below. >> >> - - - >> >> 1) Why building a variant kernel with ipmi_si as a module is not >> feasible: >> >> Stratus sells servers based upon Red Hat Enterprise Linux (RHEL). >> In the next release of RHEL, ipmi_si will be built into the kernel >> so that access to ACPI opregion is available early in kernel >> startup. Stratus systems run the Red Hat kernel so that the >> system is certified and supported by Red Hat. For this reason >> using a custom kernel configured to build ipmi_si as a module is >> not an option. > >Yes, the RHEL engineer explained this to me, and it makes sense now. Thanks. > >> >> >> 2) User mode access to IPMI on Stratus systems: >> >> Although Stratus provides a replacement for ipmi_si, we depend >> on ipmi_msghandler and ipmi_devintf. The device /dev/ipmi0 is >> present and this device is utilized by the user-mode system >> management software Stratus supplies. >> >> Therefore other programs like ipmitool can send IPMI commands and >> get responses on Stratus systems. > >Ah, ok. That's good. > >> >> >> >> 3) Hot removal of the KCS interfaces discovered by ipmi_si seems >> to not do enough... One KCS cannot successfully be removed: >> >> Based upon your suggestion, we tried to use hot removal. With >> RHEL 6.4 Beta (kernel-2.6.32-343.el6), Stratus attempted to hot >> remove the IPMI interfaces. This was booted with >> "ipmi_si.trydefaults=0" >> although we expect that kernel option to have no effect since a >> BMC is found before the defaults would be tried. >> >> This is logged when ipmi_si initializes indicating that both BMCs >> were discovered: >> >> ipmi message handler version 39.2 >> IPMI System Interface driver. >> ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, >> slave address 0x0, irq 0 >> ipmi: Found new BMC (man_id: 0x77, prod_id: 0x05c6, dev_id: 0x41) >> IPMI kcs interface initialized >> ipmi_si: Adding SMBIOS-specified kcs state machine >> ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xda2, >> slave address 0x20, irq 0 >> ipmi: interfacing existing BMC (man_id: 0x77, prod_id: 0x05c6, >> dev_id: 0x41) >> IPMI kcs interface initialized >> >> Although there are two different BMCs, because it says >> "interfacing existing BMC" >> it appears that ipmi_si assumes they are the same BMC. > >That's happening in the message handler and it happens because the >manufacturer, product, and device id all match. From the spec: > >The Device ID is typically used in combination with the Product ID >field such >that the Device IDs for different controllers are unique under a >given Product >ID. A controller can optionally use the Device ID as an 'instance' >identifier if >more than one controller of that kind is used in the system. >(Section 20.1) > >Different controllers in the same system are supposed to have different >device >IDs. I have a made an inquiry to Stratus Hardware Engineering asking why our product is not compliant with the specification. I will pursue a change to future products to comply. However, Stratus has several generations of systems in the field for which this change will be very difficult. > >> Also, I notice the slave address for the first KCS (port CA2) seems >> wrong. Maybe these findings are relevant to what happens next. > >Probably not relevant. It's not correct because, for some bizarre >reason, the slave address is not present in the ACPI information. >The slave address is only used by the message handler for the >IPMB return address on messages routed over IPMB. > >It is odd that one interface is specified in ACPI and the other in DMI. >You can specify all of them in both tables. The Stratus server is actually two complete servers that operate in lockstep to provide reliable operation regardless of any single failed component. One of the two I/O subsystems is active during BIOS POST. Only information about the active subsystem is placed in the SMBIOS data structure. Thus dmidecode shows this info for either port CA2 or DA2 depending upon which I/O CRU was active: Handle 0x0048, DMI type 38, 18 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 2.0 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0DA2 (I/O)
Re: 3.8.0-rc0 on xen-unstable: RCU Stall during boot as dom0 kernel after IOAPIC
On Mon, Dec 17, 2012 at 03:46:34PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 17, 2012 at 09:32:17PM +0100, Sander Eikelenboom wrote:
> >
> > Sunday, December 16, 2012, 6:38:24 PM, you wrote:
> >
> > > On Fri, Dec 14, 2012 at 04:55:57PM +0100, Sander Eikelenboom wrote:
> > >> Hi Konrad,
> > >>
> > >> I just tried to boot a 3.8.0-rc0 kernel (last commit:
> > >> 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with
> > >> current xen-unstable.
> >
> > > Yeah, saw it over the Dec 11->Dec 12 merges and was out on
> > > vacation during that time (just got back).
> >
> > > Did you by any chance try to do a git bisect to narrow down
> > > which merge it was?
> >
> > Hi Konrad,
>
> Hey Sander,
>
> Thank you for doing the bisection.
>
> Fenghua - any ideas what might be amiss in the Xen subsystem?
> I hadn't looked at the patchset of the CPU0 offlining/onlining
> so I am not completly up to speed on the particulars of the patches.
> > 30106c174311b8cfaaa3186c7f6f9c36c62d17da is the first bad commit
> > commit 30106c174311b8cfaaa3186c7f6f9c36c62d17da
> > Author: Fenghua Yu
> > Date: Tue Nov 13 11:32:41 2012 -0800
> >
> > x86, hotplug: Support functions for CPU0 online/offline
> >
> > Add smp_store_boot_cpu_info() to store cpu info for BSP during boot
> > time.
> >
> > Now smp_store_cpu_info() stores cpu info for bringing up BSP or AP after
> > it's offline.
> >
> > Continue to online CPU0 in native_cpu_up().
> >
> > Continue to offline CPU0 in native_cpu_disable().
> >
> > Signed-off-by: Fenghua Yu
> > Link:
> > http://lkml.kernel.org/r/1352835171-3958-5-git-send-email-fenghua...@intel.com
> > Signed-off-by: H. Peter Anvin
> >
This patch:
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..4f7d259 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -254,7 +254,7 @@ static void __init xen_smp_prepare_cpus(unsigned int
max_cpus)
}
xen_init_lock_cpu(0);
- smp_store_cpu_info(0);
+ smp_store_boot_cpu_info();
cpu_data(0).x86_max_cores = 1;
for_each_possible_cpu(i) {
Would do the corresponding change in the Xen subsystem that the above
mentioned commit did. Perhaps that is all that is needed? I am going to
be able to test this and look in more details tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 10:08:02PM +0100, Borislav Petkov wrote: > On Mon, Dec 17, 2012 at 12:59:00PM -0800, Joe Perches wrote: > > The new pr_emerg is effectively a termination of the > > previous one. There's no need for 2 consecutive uses > > of pr_emerg(HW_ERR ...) here. > > Actually, in decode_mc5_mce(), the second pr_emerg needs to stay like > what it is now. > > So Jacob, please leave those changes out, I'll sort them out later. Okay, will do, I'll change fix it in my changes then. But I'll wait for your feedback tomorrow, before sending out V2. Thanks! -Jacob > > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 12:59:00PM -0800, Joe Perches wrote:
> On Mon, 2012-12-17 at 14:43 -0600, Jacob Shin wrote:
> > On Mon, Dec 17, 2012 at 09:40:11PM +0100, Borislav Petkov wrote:
> > > On Mon, Dec 17, 2012 at 12:34:35PM -0800, Joe Perches wrote:
> > > > decode_mc2_mce does
> > > >
> > > > pr_emerg(HW_ERR "MC2 Error: ");
> > > > calls
> > > > fam_ops->mc2_mce()
> > > > which may not emit anything
> > > > and if it doesn't, does
> > > > pr_emerg(HW_ERR "Corrupted ...");
> > > > on another line leaving a trailing colon without
> > > > newline from the pr_emerg above.
> > >
> > > Ok, this is in Jacob's patch AFAICT, I'll review those tomorrow but
> > > thanks for the heads-up.
> >
> > Okay, I'll wait until your feedback before sending V2
> >
> > >
> > > > I believe the second pr_emerg should be pr_cont
> > >
> > > Actually, it should be
> > >
> > > pr_emerg(HW_ERR "\nCorrupted...\n");
> > >
> > > to finish the initial pr_emerg.
> >
> > Okay, all of the other decode_mc*_mce functions needs to change then.
>
> Hi Jacob.
>
> I don't think that's necessary.
>
> Using any pr_("\n...") is just not good form.
> I think the pr_cont would be fine, it's the same
> form as all the other decoded continuations.
>
> The new pr_emerg is effectively a termination of the
> previous one. There's no need for 2 consecutive uses
> of pr_emerg(HW_ERR ...) here.
Ah, okay, I'll use pr_cont. Thanks!
-Jacob
>
> cheers, Joe
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL[ block drivers bits for 3.8
Hi Linus,
Now that the core bits are in, here are the driver bits for 3.8. The
branch contains:
- A huge pile of drbd bits that were dumped from the 3.7 merge window.
Following that, it was both made perfectly clear that there is going to be
no more over-the-wall pulls and how the situation on individual pulls can
be improved.
- A few cleanups from Akinobu Mita for drbd and cciss.
- Queue improvement for loop from Lukas. This grew into adding a generic
interface for waiting/checking an even with a specific lock, allowing
this to be pulled out of md and now loop and drbd is also using it.
- A few fixes for xen back/front block driver from Roger Pau Monne.
- Partition improvements from Stephen Warren, allowing partiion UUID to be
used as an identifier.
You will have a merge conflict to resolve in
drivers/block/xen-blkback/common.h which should end up looking like
this:
unsigned intflush_support:1;
unsigned intdiscard_secure:1;
unsigned intfeature_gnt_persistent:1;
unsigned intoverflow_max_grants:1;
Please pull!
git://git.kernel.dk/linux-block.git for-3.8/drivers
Akinobu Mita (3):
drbd: use copy_highpage
cciss: cleanup bitops usage
cciss: use check_signature()
Andreas Gruenbacher (210):
drbd: Get rid of req_validator_fn typedef
drbd: Remove superfluous declaration
drbd: Consistently use block_id == ID_SYNCER for checksum based resync
and online verify
drbd: Get rid of BE_DRBD_MAGIC and BE_DRBD_MAGIC_BIG
drbd: Endianness convert the constants instead of the variables
drbd: Magic reserved block_id value cleanup
drbd: Move drbd_free_tl_hash() to drbd_main()
drbd: Update outdated comment
drbd: Request lookup code cleanup (1)
drbd: Request lookup code cleanup (2)
drbd: Request lookup code cleanup (3)
drbd: Request lookup code cleanup (4)
drbd: Add interval tree data structure
drbd: Put sector and size in struct drbd_request into struct drbd_interval
drbd: Use interval tree for overlapping write request detection
drbd: Add read_requests tree
drbd: Use the read and write request trees for request lookups
drbd: Put sector and size in struct drbd_epoch_entry into struct
drbd_interval
drbd: Use interval tree for overlapping epoch entry detection
drbd: Remove the unused hash tables
drbd: Convert all constants in enum drbd_req_event to upper case
drbd: Convert all constants in enum drbd_thread_state to upper case
drbd: Replace the ERR_IF macro with an assert-like macro
drbd: Remove some useless paranoia code
drbd: Inline function overlaps() is now unused
drbd: Interval tree bugfix
drbd: Move cmdname() out of drbd_int.h
drbd: Rename "enum drbd_packets" to "enum drbd_packet"
drbd: Remove redundant initialization
drbd: Initialize the sequence number sent over the network even when not
used
drbd: Move sequence number logic into drbd_receiver.c and simplify it
drbd: Move some functions to where they are used
drbd: struct drbd_request: Introduce a new collision flag
drbd: Remove redundant check from drbd_contains_interval()
drbd: Allow to wait for the completion of an epoch entry as well
drbd: _req_conflicts(): Get rid of the epoch_entries tree
drbd: Remove unnecessary reference counting left-over
drbd: Defer new writes when detecting conflicting writes
drbd: Make the peer_seq updating code more obvious
drbd: Improve the drbd_find_overlap() documentation
drbd: Remove unused variable in struct drbd_conf
drbd: Rename struct drbd_epoch_entry to struct drbd_peer_request
drbd: Clean up some left-overs
drbd: Update some comments
drbd: Local variable renames: e -> peer_req
drbd: Rename drbd_submit_ee -> drbd_submit_peer_request
drbd: Rename drbd_endio_{pri,sec} -> drbd_{,peer_}request_endio
drbd: Iterate over all overlapping intervals in a tree
drbd: Remove obsolete comment
drbd: Use the IS_ALIGNED() macro in some more places
drbd: Use container_of() instead of casting
drbd: Concurrent write detection fix
drbd: Replace atomic_add_return with atomic_inc_return
drbd: Use ping-timeout when waiting for missing ack packets
drbd: Improve how conflicting writes are handled
drbd: Remove redundant check
drbd: Get rid of P_MAX_CMD
drbd: Replace get_asender_cmd() with its implementation
drbd: Remove left-over function prototypes
drbd: drbd_send(): Return a "real" error code if we have no socket
drbd: drbd_get_data_sock(): Return 0 upon success and an error code
otherwise
drbd: Add drbd_send_all(): Send an entire buffer
drbd: conn_send_cmd2(): Return 0 upon success and an error code otherwise
drbd: _conn_send_cmd(): Return 0 upon success
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 12:59:00PM -0800, Joe Perches wrote: > The new pr_emerg is effectively a termination of the > previous one. There's no need for 2 consecutive uses > of pr_emerg(HW_ERR ...) here. Actually, in decode_mc5_mce(), the second pr_emerg needs to stay like what it is now. So Jacob, please leave those changes out, I'll sort them out later. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On 12/13/2012 11:59 PM, Venu Byravarasu wrote: > As Tegra USB host driver is using instance number for resetting > PORT0 twice, adding a new DT property for handling this. Alan, Greg, Felip,e This series looks fine to me. I'd like to take all the Tegra-related USB patches through the Tegra tree for 3.9 if possible (so I'm looking for your acks here). I believe Venu plans to significantly clean up the EHCI/PHY driver split for Tegra, rework the drivers, and add support for Tegra30 in addition to Tegra20. Some of this requires changes to some Tegra board files and device trees to maintain "git bisect" I don't know for sure yet, but I believe that rework may also end up conflicting with other clock-related rework that will show up for Tegra in 3.9. Are you OK with this? I'll certainly look for your review/acks on the patches before picking them up though. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 3.6.10: Intel: ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
-Original Message- From: devendra.aaru [mailto:devendra.a...@gmail.com] Sent: Monday, December 17, 2012 1:39 PM To: Justin Piszcz Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org Subject: Re: 3.6.10: Intel: ixgbe :01:00.0 eth4: Detected Tx Unit Hang Ccing netdev On Sat, Dec 15, 2012 at 10:49 AM, Justin Piszcz wrote: > Hello, > > Kernel 3.6.10, first time I have seen this that I can remember (on 10GbE) > anyway, is this a known issue with 3.6.10? > > When the link went down is when I rebooted/etc the remote host attached on > the other end. > I've not changed anything physically with the hardware and have been on > 3.6.0-3.6.9 and noticed this when I moved to 3.6.10. -- > I don't believe we have seen Tx hangs in validation. If you could narrow down the conditions that lead to the Tx hang that would help a lot. Also > the output of ethtool -S eth4 after the Tx hang occurs can be useful to get an idea of the load on the interface. > Thanks, > Emil -- In this case I only have two servers that mount each other's NFS volumes and that were idle at the time, I rebooted one of the systems and that is when I saw this, if I can get something to repeat/pattern and/or the ethtool output I will update this thread, thank you. Justin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] driver i2c-nforce2: fix pointer CodingStyle issues
fix these errors reported by checkpatch.pl
- drivers/i2c/busses/i2c-nforce2.c:191
- drivers/i2c/busses/i2c-nforce2.c:193
ERROR: "foo * bar" should be "foo *bar"
- drivers/i2c/busses/i2c-nforce2.c:302:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Laurent Navet
---
drivers/i2c/busses/i2c-nforce2.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nforce2.c b/drivers/i2c/busses/i2c-nforce2.c
index 392303b..9db5ff5 100644
--- a/drivers/i2c/busses/i2c-nforce2.c
+++ b/drivers/i2c/busses/i2c-nforce2.c
@@ -188,9 +188,9 @@ static int nforce2_check_status(struct i2c_adapter *adap)
}
/* Return negative errno on error */
-static s32 nforce2_access(struct i2c_adapter * adap, u16 addr,
+static s32 nforce2_access(struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
- u8 command, int size, union i2c_smbus_data * data)
+ u8 command, int size, union i2c_smbus_data *data)
{
struct nforce2_smbus *smbus = adap->algo_data;
unsigned char protocol, pec;
@@ -299,7 +299,7 @@ static u32 nforce2_func(struct i2c_adapter *adapter)
return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
I2C_FUNC_SMBUS_PEC |
- (((struct nforce2_smbus*)adapter->algo_data)->blockops ?
+ (((struct nforce2_smbus *)adapter->algo_data)->blockops ?
I2C_FUNC_SMBUS_BLOCK_DATA : 0);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
On Mon, 17 Dec 2012, Benoit Cousson wrote: > It was done for legacy reason but should disappear once the modulemode > will be be removed from the clock nodes. Here's a start at taking care of the low-hanging fruit: http://marc.info/?l=linux-omap=135577685007813=2 Only lightly tested, so tests with Kconfigs with lots of OMAP drivers enabled would be appreciated. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] clk: vt8500: Use of_init_clk_data()
Reduce lines of code and simplify this driver by using the
generic clock binding parsing function.
Signed-off-by: Stephen Boyd
Cc: Tony Prisk
---
drivers/clk/clk-vt8500.c | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index fe25570..454efa7 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -200,8 +200,6 @@ static __init void vtwm_device_clk_init(struct device_node
*node)
u32 en_reg, div_reg;
struct clk *clk;
struct clk_device *dev_clk;
- const char *clk_name = node->name;
- const char *parent_name;
struct clk_init_data init;
int rc;
int clk_init_flags = 0;
@@ -237,8 +235,6 @@ static __init void vtwm_device_clk_init(struct device_node
*node)
clk_init_flags |= CLK_INIT_DIVISOR;
}
- of_property_read_string(node, "clock-output-names", _name);
-
switch (clk_init_flags) {
case CLK_INIT_GATED:
init.ops = _gated_clk_ops;
@@ -256,11 +252,11 @@ static __init void vtwm_device_clk_init(struct
device_node *node)
return;
}
- init.name = clk_name;
- init.flags = 0;
- parent_name = of_clk_get_parent_name(node, 0);
- init.parent_names = _name;
- init.num_parents = 1;
+ rc = of_init_clk_data(node, );
+ if (WARN_ON(rc)) {
+ kfree(dev_clk);
+ return;
+ }
dev_clk->hw.init =
@@ -270,7 +266,7 @@ static __init void vtwm_device_clk_init(struct device_node
*node)
return;
}
rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
- clk_register_clkdev(clk, clk_name, NULL);
+ clk_register_clkdev(clk, init.name, NULL);
}
@@ -458,8 +454,6 @@ static __init void vtwm_pll_clk_init(struct device_node
*node, int pll_type)
u32 reg;
struct clk *clk;
struct clk_pll *pll_clk;
- const char *clk_name = node->name;
- const char *parent_name;
struct clk_init_data init;
int rc;
@@ -475,24 +469,21 @@ static __init void vtwm_pll_clk_init(struct device_node
*node, int pll_type)
pll_clk->lock = &_lock;
pll_clk->type = pll_type;
- of_property_read_string(node, "clock-output-names", _name);
-
- init.name = clk_name;
init.ops = _pll_ops;
- init.flags = 0;
- parent_name = of_clk_get_parent_name(node, 0);
- init.parent_names = _name;
- init.num_parents = 1;
+ rc = of_init_clk_data(node, );
+ if (WARN_ON(rc))
+ goto err;
pll_clk->hw.init =
clk = clk_register(NULL, _clk->hw);
- if (WARN_ON(IS_ERR(clk))) {
- kfree(pll_clk);
- return;
- }
+ if (WARN_ON(IS_ERR(clk)))
+ goto err;
rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
- clk_register_clkdev(clk, clk_name, NULL);
+ clk_register_clkdev(clk, init.name, NULL);
+ return;
+err:
+ kfree(pll_clk);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] clk: Add of_init_clk_data() to parse common clock bindings
Consolidate DT parsing for the common bits of a clock binding in
one place to simplify clock drivers. This also has the added
benefit of standardizing how the clock names used by the common
clock framework are generated from the DT bindings. We always use
the first clock-output-names string if it exists, otherwise we
fall back to the node name.
To be slightly more efficient and make the caller's life easier,
we introduce a shallow copy flag so that the clock core knows to
just copy the pointers to the strings and not the string
contents. Otherwise the callers of this function would have to
free the strings allocated here which could be cumbersome.
Signed-off-by: Stephen Boyd
Cc: Rob Herring
---
drivers/clk/clk.c| 58 +++-
include/linux/clk-provider.h | 2 ++
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 251e45d..95380a9 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1383,6 +1383,10 @@ static int _clk_register(struct device *dev, struct
clk_hw *hw, struct clk *clk)
{
int i, ret;
+ hw->clk = clk;
+ if (hw->init->flags & CLK_SHALLOW_COPY)
+ return PTR_RET(__clk_register(dev, hw));
+
clk->name = kstrdup(hw->init->name, GFP_KERNEL);
if (!clk->name) {
pr_err("%s: could not allocate clk->name\n", __func__);
@@ -1393,7 +1397,6 @@ static int _clk_register(struct device *dev, struct
clk_hw *hw, struct clk *clk)
clk->hw = hw;
clk->flags = hw->init->flags;
clk->num_parents = hw->init->num_parents;
- hw->clk = clk;
/* allocate local copy in case parent_names is __initdata */
clk->parent_names = kzalloc((sizeof(char*) * clk->num_parents),
@@ -1797,4 +1800,57 @@ void __init of_clk_init(const struct of_device_id
*matches)
clk_init_cb(np);
}
}
+
+/**
+ * of_init_clk_data() - Initialize a clk_init_data struct from a DT node
+ * @np: node to initialize struct from
+ * @init: struct to initialize
+ *
+ * Populates the clk_init_data struct by parsing the device node for
+ * properties matching the common clock binding. Returns 0 on success
+ * and a negative error code on failure.
+ */
+int of_init_clk_data(struct device_node *np, struct clk_init_data *init)
+{
+ struct of_phandle_args s;
+ const char **names = NULL, **p;
+ const char *name;
+ int i;
+
+ if (of_property_read_string(np, "clock-output-names", ) < 0)
+ name = np->name;
+ init->name = kstrdup(name, GFP_KERNEL);
+ if (!init->name)
+ return -ENOMEM;
+
+ for (i = 0; of_parse_phandle_with_args(np, "clocks", "#clock-cells",
+ i, ) == 0; i++) {
+ p = krealloc(names, sizeof(*names) * (i + 1), GFP_KERNEL);
+ if (!p)
+ goto err;
+ names = p;
+
+ if (of_property_read_string(s.np, "clock-output-names",
+ ) < 0)
+ name = s.np->name;
+ names[i] = kstrdup(name, GFP_KERNEL);
+ if (!names[i])
+ goto err;
+ of_node_put(s.np);
+ }
+
+ init->parent_names = names;
+ init->num_parents = i;
+ init->flags = CLK_SHALLOW_COPY;
+
+ return 0;
+err:
+ of_node_put(s.np);
+ while (--i >= 0)
+ kfree(names[i]);
+ kfree(names);
+ kfree(init->name);
+ return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(of_init_clk_data);
#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 4989b8a..9d3db2b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -27,6 +27,7 @@
#define CLK_IS_ROOTBIT(4) /* root clk, has no parent */
#define CLK_IS_BASIC BIT(5) /* Basic clk, can't do a to_clk_foo() */
#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */
+#define CLK_SHALLOW_COPY BIT(7) /* don't copy the initdata strings */
struct clk_hw;
@@ -380,6 +381,7 @@ struct clk_onecell_data {
struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void
*data);
const char *of_clk_get_parent_name(struct device_node *np, int index);
void of_clk_init(const struct of_device_id *matches);
+int of_init_clk_data(struct device_node *np, struct clk_init_data *init);
#endif /* CONFIG_COMMON_CLK */
#endif /* CLK_PROVIDER_H */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Introduce of_init_clk_data() for DT clock parsing
I see the same pattern repeated a few times to parse the common clock bindings for a particular clock. Instead of wrting this code another time, let's consolidate the logic in one place and standardize how clocks will be named from their bindings. After this series there are no more users of of_clk_get_parent_name() so we may want to delete it. Stephen Boyd (4): clk: Add of_init_clk_data() to parse common clock bindings clk: highbank: Use of_init_clk_data() clk: vt8500: Use of_init_clk_data() clk: zynq: Use of_init_clk_data() drivers/clk/clk-highbank.c | 21 ++-- drivers/clk/clk-vt8500.c | 39 - drivers/clk/clk-zynq.c | 28 +++-- drivers/clk/clk.c| 58 +++- include/linux/clk-provider.h | 2 ++ 5 files changed, 91 insertions(+), 57 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] clk: highbank: Use of_init_clk_data()
Reduce lines of code and simplify this driver by using the
generic clock binding parsing function.
Signed-off-by: Stephen Boyd
Cc: Rob Herring
---
drivers/clk/clk-highbank.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/clk-highbank.c b/drivers/clk/clk-highbank.c
index 52fecad..5dbbf62 100644
--- a/drivers/clk/clk-highbank.c
+++ b/drivers/clk/clk-highbank.c
@@ -275,8 +275,6 @@ static __init struct clk *hb_clk_init(struct device_node
*node, const struct clk
u32 reg;
struct clk *clk;
struct hb_clk *hb_clk;
- const char *clk_name = node->name;
- const char *parent_name;
struct clk_init_data init;
int rc;
@@ -290,24 +288,21 @@ static __init struct clk *hb_clk_init(struct device_node
*node, const struct clk
hb_clk->reg = sregs_base + reg;
- of_property_read_string(node, "clock-output-names", _name);
-
- init.name = clk_name;
init.ops = ops;
- init.flags = 0;
- parent_name = of_clk_get_parent_name(node, 0);
- init.parent_names = _name;
- init.num_parents = 1;
+ rc = of_init_clk_data(node, );
+ if (WARN_ON(rc))
+ goto err;
hb_clk->hw.init =
clk = clk_register(NULL, _clk->hw);
- if (WARN_ON(IS_ERR(clk))) {
- kfree(hb_clk);
- return NULL;
- }
+ if (WARN_ON(IS_ERR(clk)))
+ goto err;
rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
return clk;
+err:
+ kfree(hb_clk);
+ return NULL;
}
static void __init hb_pll_init(struct device_node *node)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] clk: zynq: Use of_init_clk_data()
Reduce lines of code and simplify this driver by using the
generic clock binding parsing function. This also fixes a bug
where the 'flags' member of the init struct is not initialized.
Signed-off-by: Stephen Boyd
Cc: Josh Cartwright
Cc: Soren Brinkmann
---
drivers/clk/clk-zynq.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/clk/clk-zynq.c b/drivers/clk/clk-zynq.c
index 37a3051..0fcc23d 100644
--- a/drivers/clk/clk-zynq.c
+++ b/drivers/clk/clk-zynq.c
@@ -48,7 +48,6 @@ static void __init zynq_pll_clk_setup(struct device_node *np)
{
struct clk_init_data init;
struct zynq_pll_clk *pll;
- const char *parent_name;
struct clk *clk;
u32 regs[2];
int ret;
@@ -64,12 +63,10 @@ static void __init zynq_pll_clk_setup(struct device_node
*np)
pll->pll_ctrl = slcr_base + regs[0];
pll->pll_cfg = slcr_base + regs[1];
- of_property_read_string(np, "clock-output-names", );
-
+ ret = of_init_clk_data(np, );
+ if (WARN_ON(ret))
+ return;
init.ops = _pll_clk_ops;
- parent_name = of_clk_get_parent_name(np, 0);
- init.parent_names = _name;
- init.num_parents = 1;
pll->hw.init =
@@ -119,13 +116,11 @@ static const struct clk_ops zynq_periph_clk_ops = {
static void __init zynq_periph_clk_setup(struct device_node *np)
{
struct zynq_periph_clk *periph;
- const char *parent_names[3];
struct clk_init_data init;
int clk_num = 0, err;
const char *name;
struct clk *clk;
u32 reg;
- int i;
err = of_property_read_u32(np, "reg", );
if (WARN_ON(err))
@@ -138,12 +133,10 @@ static void __init zynq_periph_clk_setup(struct
device_node *np)
periph->clk_ctrl = slcr_base + reg;
spin_lock_init(>clkact_lock);
- init.name = np->name;
+ err = of_init_clk_data(np, );
+ if (WARN_ON(err))
+ return;
init.ops = _periph_clk_ops;
- for (i = 0; i < ARRAY_SIZE(parent_names); i++)
- parent_names[i] = of_clk_get_parent_name(np, i);
- init.parent_names = parent_names;
- init.num_parents = ARRAY_SIZE(parent_names);
periph->hw.init =
@@ -315,7 +308,6 @@ err_read_output_name:
static void __init zynq_cpu_clk_setup(struct device_node *np)
{
struct zynq_cpu_clk *cpuclk;
- const char *parent_names[3];
struct clk_init_data init;
void __iomem *clk_621;
struct clk *clk;
@@ -335,12 +327,10 @@ static void __init zynq_cpu_clk_setup(struct device_node
*np)
clk_621 = slcr_base + reg[1];
spin_lock_init(>clkact_lock);
- init.name = np->name;
+ err = of_init_clk_data(np, );
+ if (WARN_ON(err))
+ return;
init.ops = _cpu_clk_ops;
- for (i = 0; i < ARRAY_SIZE(parent_names); i++)
- parent_names[i] = of_clk_get_parent_name(np, i);
- init.parent_names = parent_names;
- init.num_parents = ARRAY_SIZE(parent_names);
cpuclk->hw.init =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] user namespace fixes
Andy Lutomirski writes: > On Fri, Dec 14, 2012 at 2:01 PM, Eric W. Biederman > wrote: >> >> These are fixes from Andys review of my user namespace tree. >> >> The first two patches are critical must fix fixes. >> >> The third patch fixing commit_creds is a nice to have but fixing it >> would be good. >> >> Andy, Serge if you could give these patches a once over to make certain >> I am not doing something stupid. >> >> Thank you, >> Eric >> >> --- >> >> Eric W. Biederman (4): >> Fix cap_capable to only allow owners in the parent user namespace to >> have caps. > > For whatever reason, I didn't get the actual email. How weird. > Assuming this is > 5e4a08476b50fa39210fca82e03325cc46b9c235: It is the parent of that 5e4a08476b50fa39210fca82e03325cc46b9c235 520d9eabce18edfef76a60b7b839d54facafe1f9 But that should be close enough. > Acked-by: Andy Lutomirski Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] menuconfig: Get rid of the top-level entries for "Load an Alternate/Save an Alternate"
Wang, All, On Monday 17 December 2012 Wang YanQing wrote: > Now we have Load/Save buttons to do the Load/Save > in the convenient place, so we can drop the > top-level entries. > > Signed-off-by: Wang YanQing Reviewed-by: "Yann E. MORIN" Tested-by: "Yann E. MORIN" Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the final tree
On Mon, 17 Dec 2012 14:34:15 +1100
Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 17 Dec 2012 14:22:38 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the final tree, today's linux-next build (powerpc allnoconfig)
> > produced this warning:
> >
> > warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> > (HAVE_GENERIC_HARDIRQS && (IRQ_DOMAIN && DEBUG_FS || MAY_HAVE_SPARSE_IRQ))
> >
> > I don't know what introduced that.
>
> Actually probably caused by commit a1eaa3bc8247 ("Kconfig: fix Irq
> Subsystem menu") from the akpm tree.
kconfig-fix-irq-subsystem-menu.patch was causing various problems so I
have dropped it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, 2012-12-17 at 14:43 -0600, Jacob Shin wrote:
> On Mon, Dec 17, 2012 at 09:40:11PM +0100, Borislav Petkov wrote:
> > On Mon, Dec 17, 2012 at 12:34:35PM -0800, Joe Perches wrote:
> > > decode_mc2_mce does
> > >
> > > pr_emerg(HW_ERR "MC2 Error: ");
> > > calls
> > > fam_ops->mc2_mce()
> > > which may not emit anything
> > > and if it doesn't, does
> > > pr_emerg(HW_ERR "Corrupted ...");
> > > on another line leaving a trailing colon without
> > > newline from the pr_emerg above.
> >
> > Ok, this is in Jacob's patch AFAICT, I'll review those tomorrow but
> > thanks for the heads-up.
>
> Okay, I'll wait until your feedback before sending V2
>
> >
> > > I believe the second pr_emerg should be pr_cont
> >
> > Actually, it should be
> >
> > pr_emerg(HW_ERR "\nCorrupted...\n");
> >
> > to finish the initial pr_emerg.
>
> Okay, all of the other decode_mc*_mce functions needs to change then.
Hi Jacob.
I don't think that's necessary.
Using any pr_("\n...") is just not good form.
I think the pr_cont would be fine, it's the same
form as all the other decoded continuations.
The new pr_emerg is effectively a termination of the
previous one. There's no need for 2 consecutive uses
of pr_emerg(HW_ERR ...) here.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] efi_pstore: Avoid deadlock in non-blocking paths
[Issue]
There is a scenario which efi_pstore may hang up:
- cpuA grabs efivars->lock
- cpuB panics and calls smp_send_stop
- smp_send_stop sends IRQ to cpuA
- after 1 second, cpuB gives up on cpuA and sends an NMI instead
- cpuA is now in an NMI handler while still holding efivars->lock
- cpuB is deadlocked
This case may happen if a firmware has a bug and
cpuA is stuck talking with it.
[Solution]
This patch changes a spin_lock to a spin_trylock in non-blocking paths.
and if the spin_lock has already taken by another cpu,
it returns without accessing to a firmware to avoid the deadlock.
Signed-off-by: Seiji Aguchi
---
drivers/firmware/efivars.c | 11 ++-
fs/pstore/platform.c |6 +++---
include/linux/pstore.h |6 ++
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 52c5d89..25d464e 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -1210,7 +1210,16 @@ static int efi_pstore_write(enum pstore_type_id type,
u64 storage_space, remaining_space, max_variable_size;
efi_status_t status = EFI_NOT_FOUND;
- spin_lock(>lock);
+ if (pstore_is_non_blocking_path(reason)) {
+ /*
+* If the lock is taken by another cpu in non-blocking path,
+* this driver returns without entering firmware to avoid
+* hanging up.
+*/
+ if (!spin_trylock(>lock))
+ return -EBUSY;
+ } else
+ spin_lock(>lock);
/*
* Check if there is a space enough to log.
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index b87d1de..f959eba 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -96,7 +96,7 @@ static const char *get_reason_str(enum kmsg_dump_reason
reason)
}
}
-static bool is_non_blocking_path(enum kmsg_dump_reason reason)
+bool pstore_is_non_blocking_path(enum kmsg_dump_reason reason)
{
/*
* In case of NMI path, pstore shouldn't be blocked
@@ -134,7 +134,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
why = get_reason_str(reason);
- if (is_non_blocking_path(reason)) {
+ if (pstore_is_non_blocking_path(reason)) {
is_locked = spin_trylock_irqsave(>buf_lock, flags);
if (!is_locked) {
pr_err("pstore dump routine blocked in %s path, may
corrupt error record\n"
@@ -165,7 +165,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
total += hsize + len;
part++;
}
- if (is_non_blocking_path(reason)) {
+ if (pstore_is_non_blocking_path(reason)) {
if (is_locked)
spin_unlock_irqrestore(>buf_lock, flags);
} else
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 1788909..595a040 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -68,12 +68,18 @@ struct pstore_info {
#ifdef CONFIG_PSTORE
extern int pstore_register(struct pstore_info *);
+extern bool pstore_is_non_blocking_path(enum kmsg_dump_reason reason);
#else
static inline int
pstore_register(struct pstore_info *psi)
{
return -ENODEV;
}
+static inline bool
+pstore_is_non_blocking_path(enum kmsg_dump_reason reason)
+{
+ return false;
+}
#endif
#endif /*_LINUX_PSTORE_H*/
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] pstore: Avoid deadlock in panic and emergency-restart path
[Issue]
When pstore is in panic and emergency-restart paths, it may be blocked
in those paths because it simply takes spin_lock.
This is an example scenario which pstore may hang up in a panic path:
- cpuA grabs psinfo->buf_lock
- cpuB panics and calls smp_send_stop
- smp_send_stop sends IRQ to cpuA
- after 1 second, cpuB gives up on cpuA and sends an NMI instead
- cpuA is now in an NMI handler while still holding buf_lock
- cpuB is deadlocked
This case may happen if a firmware has a bug and
cpuA is stuck talking with it more than one second.
Also, this is a similar scenario in an emergency-restart path:
- cpuA grabs psinfo->buf_lock and stucks in a firmware
- cpuB kicks emergency-restart via either sysrq-b or hangcheck timer.
And then, cpuB is deadlocked by taking psinfo->buf_lock again.
[Solution]
This patch avoids the deadlocking issues in both panic and emergency_restart
paths by introducing a function, is_non_blocking_path(), to check if a cpu
can be blocked in current path.
With this patch, pstore is not blocked even if another cpu has
taken a spin_lock, in those paths by changing from spin_lock_irqsave
to spin_trylock_irqsave.
In addition, according to a comment of emergency_restart() in kernel/sys.c,
spin_lock shouldn't be taken in an emergency_restart path to avoid
deadlock. This patch fits the comment below.
/**
* emergency_restart - reboot the system
*
* Without shutting down any hardware or taking any locks
* reboot the system. This is called when we know we are in
* trouble so this is our best effort to reboot. This is
* safe to call in interrupt context.
*/
void emergency_restart(void)
Signed-off-by: Seiji Aguchi
---
fs/pstore/platform.c | 34 --
1 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 5ea2e77..b87d1de 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -96,6 +96,26 @@ static const char *get_reason_str(enum kmsg_dump_reason
reason)
}
}
+static bool is_non_blocking_path(enum kmsg_dump_reason reason)
+{
+ /*
+* In case of NMI path, pstore shouldn't be blocked
+* regardless of reason.
+*/
+ if (in_nmi())
+ return true;
+
+ switch (reason) {
+ /* In panic case, other cpus are stopped by smp_send_stop(). */
+ case KMSG_DUMP_PANIC:
+ /* Emergency restart shouldn't be blocked by spin lock. */
+ case KMSG_DUMP_EMERG:
+ return true;
+ default:
+ return false;
+ }
+}
+
/*
* callback from kmsg_dump. (s2,l2) has the most recently
* written bytes, older bytes are in (s1,l1). Save as much
@@ -114,10 +134,12 @@ static void pstore_dump(struct kmsg_dumper *dumper,
why = get_reason_str(reason);
- if (in_nmi()) {
- is_locked = spin_trylock(>buf_lock);
- if (!is_locked)
- pr_err("pstore dump routine blocked in NMI, may corrupt
error record\n");
+ if (is_non_blocking_path(reason)) {
+ is_locked = spin_trylock_irqsave(>buf_lock, flags);
+ if (!is_locked) {
+ pr_err("pstore dump routine blocked in %s path, may
corrupt error record\n"
+ , in_nmi() ? "NMI" : why);
+ }
} else
spin_lock_irqsave(>buf_lock, flags);
oopscount++;
@@ -143,9 +165,9 @@ static void pstore_dump(struct kmsg_dumper *dumper,
total += hsize + len;
part++;
}
- if (in_nmi()) {
+ if (is_non_blocking_path(reason)) {
if (is_locked)
- spin_unlock(>buf_lock);
+ spin_unlock_irqrestore(>buf_lock, flags);
} else
spin_unlock_irqrestore(>buf_lock, flags);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] pstore,efi_pstore: Avoid deadlock in non-blocking paths
Changelog v1 -> v2 - Erase a logic checking the number of online cpus. - Create a patchset to fix deadlocking issue in both pstore filesystem and efi_pstore driver. - Introduce a function, is_non_blocking_path(), to check if pstore is in panic and emergency-restart paths (PATCH 1/2) - Avoid efi_pstore_driver is blocked in non-blocking paths such as nmi, panic and emergency-restart paths (PATCH 2/2) [Issue] There are some paths which shouldn't be blocked in kernel, like NMI, panic case after stopping cpus, emergency-restart. On the other hand, current pstore avoids blocking in a NMI path but it may be blocked in other paths. Also, an efi_pstore driver may be blocked in all of those paths because it simply takes a spin lock at writing time. If they are blocked in those paths, the system will hang up and it has a big impact for users. Here is an example scenario which pstore is blocked in panic path. - cpuA grabs psinfo->buf_lock - cpuB panics and calls smp_send_stop - smp_send_stop sends IRQ to cpuA after 1 second, cpuB gives up on cpuA and sends an NMI instead - cpuA is now in an NMI handler while still holding buf_lock. And then, cpuB is deadlocked by taking efi_pstore->lock again. This case may happen if a firmware has a bug and cpuA is stuck in it. [Solution] This patchset avoids that pstore and efi_pstore driver are blocked in the non-blocking paths like NMI, panic, and emrgency-restart by introducing a function checking if they are in those paths. Please see each patch for detailed explanations. Seiji Aguchi (2): [PATCH v2 1/2] pstore: Avoid deadlock in panic and emergency-restart path [PATCH v2 2/2] efi_pstore: Avoid deadlock in non-blocking paths drivers/firmware/efivars.c | 11 ++- fs/pstore/platform.c | 34 -- include/linux/pstore.h |6 ++ 3 files changed, 44 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 12/16/2012 09:37 AM, Terje Bergström wrote: ... > ... Sure we could tell DC to ask its parent > (host1x), and call host1x driver with platform_device pointer found that > way, and host1x would return a pointer to tegradrm's data. Hanging the > data onto host1x driver is just a more complicated way of implementing > global data No it's not; at that point, the data is no longer global, but specific to the driver instance. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] cfq-iosched: implement hierarchy-ready cfq_group charge scaling
On Fri, Dec 14, 2012 at 02:41:20PM -0800, Tejun Heo wrote: > Currently, cfqg charges are scaled directly according to cfqg->weight. > Regardless of the number of active cfqgs or the amount of active > weights, a given weight value always scales charge the same way. This > works fine as long as all cfqgs are treated equally regardless of > their positions in the hierarchy, which is what cfq currently > implements. It can't work in hierarchical settings because the > interpretation of a given weight value depends on where the weight is > located in the hierarchy. I did not understand this. Why the current scheme will not work with hierarchy? While we calculate the vdisktime, this is calculated with the help of CFQ_DEFAULT_WEIGHT and cfqg->weight. So we scale used time slice in proportion to CFQ_DEFAULT_WEIGTH/cfqg->weight. So higher the weight lesser the charge and cfqg gets scheduled again faster and lower the weight, higher the vdisktime and cfqg gets scheduled less frequently. As every cfqg does the same thing on service tree, they automatically get fair share w.r.t their weight. And this mechanism should not be impacted by the hierarchy because we have a separate service tree at separate level. This will not work only if you come up with one compressed tree and then weights will have to be adjusted. If we have a separate service tree in each group then it should work just fine. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: OMAP4: PRM: Correct reset source map
Hi On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote: > In the map for reset sources register we use defines intended for > using with PRM_RSTCTRL register. So fix it. your changes look good, but they are missing Signed-off-by: lines. Could you please either resend with those, or confirm that you intended to add them? You may wish to read Documentation/SubmittingPatches, particularly item 12. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Suppress mm/memory.o warning on older compilers if !CONFIG_NUMA_BALANCING
On Mon, 17 Dec 2012 11:49:17 +
Mel Gorman wrote:
> The kbuild test robot reported the following after the merge of Automatic
> NUMA Balancing when cross-compiling for avr32.
>
> mm/memory.c: In function 'do_pmd_numa_page':
> mm/memory.c:3593: warning: no return statement in function returning non-void
>
> The code is unreachable but the avr32 cross-compiler was not new enough
> to know that. This patch suppresses the warning.
>
> Signed-off-by: Mel Gorman
> ---
> mm/memory.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e6a3b93..23f1fdf 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3590,6 +3590,7 @@ static int do_pmd_numa_page(struct mm_struct *mm,
> struct vm_area_struct *vma,
>unsigned long addr, pmd_t *pmdp)
> {
> BUG();
> + return 0;
> }
> #endif /* CONFIG_NUMA_BALANCING */
Odd. avr32's BUG() includes a call to unreachable(), which should
evaluate to "do { } while (1)". Can you check that this is working?
Perhaps it _is_ working, but the compiler incorrectly thinks that the
function can return?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc0 on xen-unstable: RCU Stall during boot as dom0 kernel after IOAPIC
On Mon, Dec 17, 2012 at 09:32:17PM +0100, Sander Eikelenboom wrote: > > Sunday, December 16, 2012, 6:38:24 PM, you wrote: > > > On Fri, Dec 14, 2012 at 04:55:57PM +0100, Sander Eikelenboom wrote: > >> Hi Konrad, > >> > >> I just tried to boot a 3.8.0-rc0 kernel (last commit: > >> 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with > >> current xen-unstable. > > > Yeah, saw it over the Dec 11->Dec 12 merges and was out on > > vacation during that time (just got back). > > > Did you by any chance try to do a git bisect to narrow down > > which merge it was? > > Hi Konrad, Hey Sander, Thank you for doing the bisection. Fenghua - any ideas what might be amiss in the Xen subsystem? I hadn't looked at the patchset of the CPU0 offlining/onlining so I am not completly up to speed on the particulars of the patches. > > With some more effort it leads to: > > git bisect start > # bad: [fa4c95bfdb85d568ae327d57aa33a4f55bab79c4] Merge branch 'for_linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs > git bisect bad fa4c95bfdb85d568ae327d57aa33a4f55bab79c4 > # good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7 > git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e > # bad: [98870901cce098bbe94d90d2c41d8d1fa8d94392] mm/bootmem.c: remove unused > wrapper function reserve_bootmem_generic() > git bisect bad 98870901cce098bbe94d90d2c41d8d1fa8d94392 > # good: [8966961b31c251b854169e9886394c2a20f2cea7] Merge tag > 'staging-3.8-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging > git bisect good 8966961b31c251b854169e9886394c2a20f2cea7 > # bad: [22a40fd9a60388aec8106b0baffc8f59f83bb1b4] Merge tag 'dlm-3.8' of > git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm > git bisect bad 22a40fd9a60388aec8106b0baffc8f59f83bb1b4 > # good: [aefb058b0c27dafb15072406fbfd92d2ac2c8790] Merge branch > 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good aefb058b0c27dafb15072406fbfd92d2ac2c8790 > # good: [b64c5fda3868cb29d5dae0909561aa7d93fb7330] Merge branch > 'timers-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good b64c5fda3868cb29d5dae0909561aa7d93fb7330 > # bad: [139353ffbe42ac7abda42f3259c1c374cbf4b779] Merge tag > 'please-pull-einj-fix-for-acpi5' of > git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras > git bisect bad 139353ffbe42ac7abda42f3259c1c374cbf4b779 > # bad: [d07e43d70eef15a44a2c328a913d8d633a90e088] Merge branch 'omap-serial' > of git://git.linaro.org/people/rmk/linux-arm > git bisect bad d07e43d70eef15a44a2c328a913d8d633a90e088 > # bad: [a05a4e24dcd73c2de4ef3f8d520b8bbb44570c60] Merge branch > 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad a05a4e24dcd73c2de4ef3f8d520b8bbb44570c60 > # bad: [a71c8bc5dfefbbf80ef90739791554ef7ea4401b] x86, topology: Debug CPU0 > hotplug > git bisect bad a71c8bc5dfefbbf80ef90739791554ef7ea4401b > # bad: [42e78e9719aa0c76711e2731b19c90fe5ae05278] x86-64, hotplug: Add > start_cpu0() entry point to head_64.S > git bisect bad 42e78e9719aa0c76711e2731b19c90fe5ae05278 > # good: [4d25031a81d3cd32edc00de6596db76cc4010685] x86, topology: Don't > offline CPU0 if any PIC irq can not be migrated out of it > git bisect good 4d25031a81d3cd32edc00de6596db76cc4010685 > # bad: [209efae12981f3d2d694499b761def10895c078c] x86, hotplug, suspend: > Online CPU0 for suspend or hibernate > git bisect bad 209efae12981f3d2d694499b761def10895c078c > # bad: [30106c174311b8cfaaa3186c7f6f9c36c62d17da] x86, hotplug: Support > functions for CPU0 online/offline > git bisect bad 30106c174311b8cfaaa3186c7f6f9c36c62d17da > > > > 30106c174311b8cfaaa3186c7f6f9c36c62d17da is the first bad commit > commit 30106c174311b8cfaaa3186c7f6f9c36c62d17da > Author: Fenghua Yu > Date: Tue Nov 13 11:32:41 2012 -0800 > > x86, hotplug: Support functions for CPU0 online/offline > > Add smp_store_boot_cpu_info() to store cpu info for BSP during boot time. > > Now smp_store_cpu_info() stores cpu info for bringing up BSP or AP after > it's offline. > > Continue to online CPU0 in native_cpu_up(). > > Continue to offline CPU0 in native_cpu_disable(). > > Signed-off-by: Fenghua Yu > Link: > http://lkml.kernel.org/r/1352835171-3958-5-git-send-email-fenghua...@intel.com > Signed-off-by: H. Peter Anvin > > :04 04 729e56e8eddaaf5d0f55257b82f28006dffb9aab > d5c98e50cd92814351ee6c741b7e4c9afa29487c M arch > > > Which seems to be merged in > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=74b84233458e9db7c160cec67638efdbec748ca9 > > -- > > Sander > > > > Thanks! > >> The boot stalls: > >> > >> [0.00] ACPI: PM-Timer IO Port: 0x808 > >> [0.00] ACPI: Local APIC address 0xfee0 > >> [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > >> [0.00] ACPI: LAPIC (acpi_id[0x02]
Re: [PATCH 06/12] cfq-iosched: implement cfq_group->nr_active and ->level_weight
On Fri, Dec 14, 2012 at 02:41:19PM -0800, Tejun Heo wrote:
> To prepare for blkcg hierarchy support, add cfqg->nr_active and
> ->level_weight. cfqg->nr_active counts the number of active cfqgs at
> the cfqg's level and ->level_weight is sum of weights of those cfqgs.
> The level covers itself (cfqg->leaf_weight) and immediate children.
This notion of level is really confusing. If one says "at cfqg's level"
I immediately associate with cfqg's siblings and not with cfqg's children.
I think confusion happens because we are overloading the definition of
cfqg. It is competing with its siblings at the same time it is competing
against its child groups (on behalf of its children tasks).
Thanks
Vivek
>
> The two values are updated when a cfqg enters and leaves the group
> service tree. Unless the hierarchy is very deep, the added overhead
> should be negligible.
>
> Currently, the parent is determined using cfqg_flat_parent() which
> makes the root cfqg the parent of all other cfqgs. This is to make
> the transition to hierarchy-aware scheduling gradual. Scheduling
> logic will be converted to use cfqg->level_weight without actually
> changing the behavior. When everything is ready,
> blkcg_weight_parent() will be replaced with proper parent function.
>
> This patch doesn't introduce any behavior chagne.
>
> Signed-off-by: Tejun Heo
> ---
> block/cfq-iosched.c | 76
> +
> 1 file changed, 76 insertions(+)
>
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 5f23763..eb290a0 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -225,6 +225,18 @@ struct cfq_group {
> u64 vdisktime;
>
> /*
> + * The number of active cfqgs and sum of their weights under this
> + * cfqg. This covers this cfqg's leaf_weight and all children's
> + * weights, but does not cover weights of further descendants.
> + *
> + * If a cfqg is on the service tree, it's active. An active cfqg
> + * also activates its parent and contributes to the level_weight of
> + * the parent.
> + */
> + int nr_active;
> + unsigned int level_weight;
> +
> + /*
>* There are two weights - (internal) weight is the weight of this
>* cfqg against the sibling cfqgs. leaf_weight is the wight of
>* this cfqg against the child cfqgs. For the root cfqg, both
> @@ -583,6 +595,22 @@ static inline struct cfq_group *blkg_to_cfqg(struct
> blkcg_gq *blkg)
> return pd_to_cfqg(blkg_to_pd(blkg, _policy_cfq));
> }
>
> +/*
> + * Determine the parent cfqg for weight calculation. Currently, cfqg
> + * scheduling is flat and the root is the parent of everyone else.
> + */
> +static inline struct cfq_group *cfqg_flat_parent(struct cfq_group *cfqg)
> +{
> + struct blkcg_gq *blkg = cfqg_to_blkg(cfqg);
> + struct cfq_group *root;
> +
> + while (blkg->parent)
> + blkg = blkg->parent;
> + root = blkg_to_cfqg(blkg);
> +
> + return root != cfqg ? root : NULL;
> +}
> +
> static inline void cfqg_get(struct cfq_group *cfqg)
> {
> return blkg_get(cfqg_to_blkg(cfqg));
> @@ -683,6 +711,7 @@ static void cfq_pd_reset_stats(struct blkcg_gq *blkg)
>
> #else/* CONFIG_CFQ_GROUP_IOSCHED */
>
> +static inline struct cfq_group *cfqg_flat_parent(struct cfq_group *cfqg) {
> return NULL; }
> static inline void cfqg_get(struct cfq_group *cfqg) { }
> static inline void cfqg_put(struct cfq_group *cfqg) { }
>
> @@ -1208,11 +1237,33 @@ cfq_update_group_weight(struct cfq_group *cfqg)
> static void
> cfq_group_service_tree_add(struct cfq_rb_root *st, struct cfq_group *cfqg)
> {
> + struct cfq_group *pos = cfqg;
> + bool propagate;
> +
> + /* add to the service tree */
> BUG_ON(!RB_EMPTY_NODE(>rb_node));
>
> cfq_update_group_weight(cfqg);
> __cfq_group_service_tree_add(st, cfqg);
> st->total_weight += cfqg->weight;
> +
> + /*
> + * Activate @cfqg and propagate activation upwards until we meet an
> + * already activated node or reach root.
> + */
> + propagate = !pos->nr_active++;
> + pos->level_weight += pos->leaf_weight;
> +
> + while (propagate) {
> + struct cfq_group *parent = cfqg_flat_parent(pos);
> +
> + if (!parent)
> + break;
> +
> + propagate = !parent->nr_active++;
> + parent->level_weight += pos->weight;
> + pos = parent;
> + }
> }
>
> static void
> @@ -1243,6 +1294,31 @@ cfq_group_notify_queue_add(struct cfq_data *cfqd,
> struct cfq_group *cfqg)
> static void
> cfq_group_service_tree_del(struct cfq_rb_root *st, struct cfq_group *cfqg)
> {
> + struct cfq_group *pos = cfqg;
> + bool propagate;
> +
> + /*
> + * Undo activation from cfq_group_service_tree_add(). Deactivate
> + * @cfqg and propagate deactivation upwards.
> + */
> + propagate = !--pos->nr_active;
> +
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 09:40:11PM +0100, Borislav Petkov wrote: > On Mon, Dec 17, 2012 at 12:34:35PM -0800, Joe Perches wrote: > > decode_mc2_mce does > > > > pr_emerg(HW_ERR "MC2 Error: "); > > calls > > fam_ops->mc2_mce() > > which may not emit anything > > and if it doesn't, does > > pr_emerg(HW_ERR "Corrupted ..."); > > on another line leaving a trailing colon without > > newline from the pr_emerg above. > > Ok, this is in Jacob's patch AFAICT, I'll review those tomorrow but > thanks for the heads-up. Okay, I'll wait until your feedback before sending V2 > > > I believe the second pr_emerg should be pr_cont > > Actually, it should be > > pr_emerg(HW_ERR "\nCorrupted...\n"); > > to finish the initial pr_emerg. Okay, all of the other decode_mc*_mce functions needs to change then. Thanks! > > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 12:34:35PM -0800, Joe Perches wrote: > decode_mc2_mce does > > pr_emerg(HW_ERR "MC2 Error: "); > calls > fam_ops->mc2_mce() > which may not emit anything > and if it doesn't, does > pr_emerg(HW_ERR "Corrupted ..."); > on another line leaving a trailing colon without > newline from the pr_emerg above. Ok, this is in Jacob's patch AFAICT, I'll review those tomorrow but thanks for the heads-up. > I believe the second pr_emerg should be pr_cont Actually, it should be pr_emerg(HW_ERR "\nCorrupted...\n"); to finish the initial pr_emerg. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: OMAP4: PRM: Correct reset source map
In the map for reset sources register we use defines intended for
using with PRM_RSTCTRL register. So fix it.
---
arch/arm/mach-omap2/prm44xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 7498bc7..e335216 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -56,9 +56,9 @@ static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
* enumeration)
*/
static struct prm_reset_src_map omap44xx_prm_reset_src_map[] = {
- { OMAP4430_RST_GLOBAL_WARM_SW_SHIFT,
+ { OMAP4430_GLOBAL_WARM_SW_RST_SHIFT,
OMAP_GLOBAL_WARM_RST_SRC_ID_SHIFT },
- { OMAP4430_RST_GLOBAL_COLD_SW_SHIFT,
+ { OMAP4430_GLOBAL_COLD_RST_SHIFT,
OMAP_GLOBAL_COLD_RST_SRC_ID_SHIFT },
{ OMAP4430_MPU_SECURITY_VIOL_RST_SHIFT,
OMAP_SECU_VIOL_RST_SRC_ID_SHIFT },
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] menuconfig: Add Save/Load buttons
Wang, All,
On Monday 17 December 2012 Wang YanQing wrote:
> If menuconfig have Save/Load button like alternative
> .config editors, xconfig, nconfig, etc.We will have
> a obvious benefit when use menuconfig just like
> when we use others, we can Save/Load our .config quickly
> and conveniently.
>
> This patch add the Save/Load button for menuconfig.
>
> [remove trailing space while at it for below line:
> "*) Formerly when I used Page Down and Page Up, the cursor would be set"
> ]
>
> Signed-off-by: Wang YanQing
[--SNIP--]
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index 53975cf..c074f8a 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
[--SNIP--]
> @@ -702,6 +709,17 @@ static void show_helptext(const char *title, const char
> *text)
> show_textbox(title, text, 0, 0);
> }
>
> +static void conf_message_callback(const char *fmt, va_list ap)
> +{
> + char buf[1024];
char buf[PATH_MAX+1];
[--SNIP--]
> @@ -948,4 +968,3 @@ int main(int ac, char **av)
>
> return res;
> }
> -
Spurious empty-line removal. Don't.
Otherwise, I've tested it, and it works great! :-)
Care to repost with the changes above (wait a bit in case of more review
by others), and you'll get my tst-by and rev'ed-by tags.
Regards,
Yann E. MORIN.
--
.-..--..
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `.---: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, 2012-12-17 at 21:22 +0100, Borislav Petkov wrote: > On Mon, Dec 17, 2012 at 12:16:16PM -0800, Joe Perches wrote: > > You also have paths where you start a pr_emerg and do not terminate it > > when there is no apparent error at all. > > For example? > decode_mc2_mce does pr_emerg(HW_ERR "MC2 Error: "); calls fam_ops->mc2_mce() which may not emit anything and if it doesn't, does pr_emerg(HW_ERR "Corrupted ..."); on another line leaving a trailing colon without newline from the pr_emerg above. I believe the second pr_emerg should be pr_cont cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc0 on xen-unstable: RCU Stall during boot as dom0 kernel after IOAPIC
Sunday, December 16, 2012, 6:38:24 PM, you wrote: > On Fri, Dec 14, 2012 at 04:55:57PM +0100, Sander Eikelenboom wrote: >> Hi Konrad, >> >> I just tried to boot a 3.8.0-rc0 kernel (last commit: >> 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with current >> xen-unstable. > Yeah, saw it over the Dec 11->Dec 12 merges and was out on > vacation during that time (just got back). > Did you by any chance try to do a git bisect to narrow down > which merge it was? Hi Konrad, With some more effort it leads to: git bisect start # bad: [fa4c95bfdb85d568ae327d57aa33a4f55bab79c4] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs git bisect bad fa4c95bfdb85d568ae327d57aa33a4f55bab79c4 # good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7 git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e # bad: [98870901cce098bbe94d90d2c41d8d1fa8d94392] mm/bootmem.c: remove unused wrapper function reserve_bootmem_generic() git bisect bad 98870901cce098bbe94d90d2c41d8d1fa8d94392 # good: [8966961b31c251b854169e9886394c2a20f2cea7] Merge tag 'staging-3.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging git bisect good 8966961b31c251b854169e9886394c2a20f2cea7 # bad: [22a40fd9a60388aec8106b0baffc8f59f83bb1b4] Merge tag 'dlm-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm git bisect bad 22a40fd9a60388aec8106b0baffc8f59f83bb1b4 # good: [aefb058b0c27dafb15072406fbfd92d2ac2c8790] Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good aefb058b0c27dafb15072406fbfd92d2ac2c8790 # good: [b64c5fda3868cb29d5dae0909561aa7d93fb7330] Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good b64c5fda3868cb29d5dae0909561aa7d93fb7330 # bad: [139353ffbe42ac7abda42f3259c1c374cbf4b779] Merge tag 'please-pull-einj-fix-for-acpi5' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras git bisect bad 139353ffbe42ac7abda42f3259c1c374cbf4b779 # bad: [d07e43d70eef15a44a2c328a913d8d633a90e088] Merge branch 'omap-serial' of git://git.linaro.org/people/rmk/linux-arm git bisect bad d07e43d70eef15a44a2c328a913d8d633a90e088 # bad: [a05a4e24dcd73c2de4ef3f8d520b8bbb44570c60] Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad a05a4e24dcd73c2de4ef3f8d520b8bbb44570c60 # bad: [a71c8bc5dfefbbf80ef90739791554ef7ea4401b] x86, topology: Debug CPU0 hotplug git bisect bad a71c8bc5dfefbbf80ef90739791554ef7ea4401b # bad: [42e78e9719aa0c76711e2731b19c90fe5ae05278] x86-64, hotplug: Add start_cpu0() entry point to head_64.S git bisect bad 42e78e9719aa0c76711e2731b19c90fe5ae05278 # good: [4d25031a81d3cd32edc00de6596db76cc4010685] x86, topology: Don't offline CPU0 if any PIC irq can not be migrated out of it git bisect good 4d25031a81d3cd32edc00de6596db76cc4010685 # bad: [209efae12981f3d2d694499b761def10895c078c] x86, hotplug, suspend: Online CPU0 for suspend or hibernate git bisect bad 209efae12981f3d2d694499b761def10895c078c # bad: [30106c174311b8cfaaa3186c7f6f9c36c62d17da] x86, hotplug: Support functions for CPU0 online/offline git bisect bad 30106c174311b8cfaaa3186c7f6f9c36c62d17da 30106c174311b8cfaaa3186c7f6f9c36c62d17da is the first bad commit commit 30106c174311b8cfaaa3186c7f6f9c36c62d17da Author: Fenghua Yu Date: Tue Nov 13 11:32:41 2012 -0800 x86, hotplug: Support functions for CPU0 online/offline Add smp_store_boot_cpu_info() to store cpu info for BSP during boot time. Now smp_store_cpu_info() stores cpu info for bringing up BSP or AP after it's offline. Continue to online CPU0 in native_cpu_up(). Continue to offline CPU0 in native_cpu_disable(). Signed-off-by: Fenghua Yu Link: http://lkml.kernel.org/r/1352835171-3958-5-git-send-email-fenghua...@intel.com Signed-off-by: H. Peter Anvin :04 04 729e56e8eddaaf5d0f55257b82f28006dffb9aab d5c98e50cd92814351ee6c741b7e4c9afa29487c M arch Which seems to be merged in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=74b84233458e9db7c160cec67638efdbec748ca9 -- Sander > Thanks! >> The boot stalls: >> >> [0.00] ACPI: PM-Timer IO Port: 0x808 >> [0.00] ACPI: Local APIC address 0xfee0 >> [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) >> [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) >> [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) >> [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) >> [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) >> [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) >> [0.00] ACPI: IOAPIC (id[0x06] address[0xfec0] gsi_base[0]) >> [0.00] IOAPIC[0]: apic_id 6, version 33, address 0xfec0, GSI 0-23 >> [0.00] ACPI: IOAPIC (id[0x07] address[0xfec2] gsi_base[24]) >> [0.00]
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 12:16:16PM -0800, Joe Perches wrote: > You also have paths where you start a pr_emerg and do not terminate it > when there is no apparent error at all. For example? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] can: add tx/rx LED trigger support
> Hi Bernd, > > On Mon, Dec 17, 2012 at 08:28:48AM +0100, Bernd Krumboeck wrote: >> Why there is no patch for any usb can device? > > Because USB canbus interfaces usually already has some dedicated > activity LED on the device itself, while this patch is meant to give an > equivalent functionality for Embedded SoC with GPIO based LEDs, so I > just started by modifying some Embedded CAN drivers. > > If you think it's useful for USB controller, just tell me or modify the > driver by yourself! As you see the patch is really easy. At least it is useful for the usb_8dev driver. I'll write a patch. Photo of the device: http://www.8devices.com/product/2/usb2can >> Can this be done in a more general way, except patching every driver? > > Actually this started as a generic patch bolted to the CAN stack, but > the implementation was too invasive and a bit too hacky. A generic > implementation at can-dev level is hard to obtain because the can-dev > layer is not used in all the device operation, as the most of the driver > calls generick network API directly. > Thanks! regards, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: common clock framwork: clk_set_rate issue
On Thu, Dec 06, 2012 at 10:52:03AM +0800, Chao Xie wrote: > hi > When develop the clk drivers for SOCs based on common clock framework. > I met a issue. > For example there is a uart device, it's function clock comes from a > divider, and the divider's parent is a mux. It means > > MUX --> DIV --> UART > > As we know that UART can work at low baudrate for a terminal, while it > can also connect to GPS module which needs a high rate. So the MUX > will provide two clock source, a low clock rate and high clock rate. > > The MUX clk driver clk-mux.c does not implement a ->round_rate callbacks. > It means that when uart driver is used for a GPS and it want to change > it clock, the driver will call clk_set_rate(); clk_set_rate will loop > upward to DIV, and DIV will try to set its divider, and it need loop > upward to MUX. > In fact the current clk drivers have some issue. > MUX clk driver should provide the round_rate callback, it then can > provide a new_rate. It means that in clk_calc_subtree MUX can switch > the clock source. It's not that simple. The input clocks to a mux may not only differ in their rate but can also have other different properties, like for example one input may be always present whereas another input only runs when the CPU is in run mode. It may be a possibility to add a flag to the mux to explicitely allow reparenting on a rate change. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, 2012-12-17 at 21:05 +0100, Borislav Petkov wrote:
> On Mon, Dec 17, 2012 at 11:57:01AM -0800, Joe Perches wrote:
> > It'd be better to change the pr_cont uses to pr_emerg
> >
> > []
> >
> > > +static void decode_mc2_mce(struct mce *m)
> > > +{
> > > + u16 ec = EC(m->status);
> > > + u8 xec = XEC(m->status, xec_mask);
> > > +
> > > + pr_emerg(HW_ERR "MC2 Error: ");
> >
> > Remove this and
> >
> > > + if (fam_ops->mc2_mce(ec, xec))
> > > + ;
> > > + else
> > > + pr_emerg(HW_ERR "Corrupted MC2 MCE info?\n");
> > > }
> >
> > And make this
> >
> > if (!fam_ops->mc2_mce(ec, xec))
> > pr_emerg(etc...);
>
> No, this is not how we do this here. We do pr_emerg in the main per-bank
> function, i.e. mc0, mc1, mc2... and we finish the line in the respective
> function with pr_cont.
>
> If your fear is line interleaving, then this shouldn't happen in most
> cases because we're in atomic #MC context and nothing else is executing
> in that case. (And I haven't seen it interleave in all my testing so
> far).
>
> If it does interleave when we have a non-critical error detected and
> reported in process context, then this whole decoding code needs a lot
> more work than this.
>
You also have paths where you start a pr_emerg and do not terminate
it when there is no apparent error at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/7] mm: vmscan: clarify how swappiness, highest priority, memcg interact
On Mon 17-12-12 13:12:33, Johannes Weiner wrote:
> A swappiness of 0 has a slightly different meaning for global reclaim
> (may swap if file cache really low) and memory cgroup reclaim (never
> swap, ever).
>
> In addition, global reclaim at highest priority will scan all LRU
> lists equal to their size and ignore other balancing heuristics.
> UNLESS swappiness forbids swapping, then the lists are balanced based
> on recent reclaim effectiveness. UNLESS file cache is running low,
> then anonymous pages are force-scanned.
>
> This (total mess of a) behaviour is implicit and not obvious from the
> way the code is organized. At least make it apparent in the code flow
> and document the conditions. It will be it easier to come up with
> sane semantics later.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Michal Hocko
Thanks!
> ---
> mm/vmscan.c | 39 ++-
> 1 file changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 648a4db..c37deaf 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1644,7 +1644,6 @@ static void get_scan_count(struct lruvec *lruvec,
> struct scan_control *sc,
> struct zone_reclaim_stat *reclaim_stat = >reclaim_stat;
> u64 fraction[2], denominator;
> enum lru_list lru;
> - int noswap = 0;
> bool force_scan = false;
> struct zone *zone = lruvec_zone(lruvec);
>
> @@ -1665,13 +1664,38 @@ static void get_scan_count(struct lruvec *lruvec,
> struct scan_control *sc,
>
> /* If we have no swap space, do not bother scanning anon pages. */
> if (!sc->may_swap || (nr_swap_pages <= 0)) {
> - noswap = 1;
> fraction[0] = 0;
> fraction[1] = 1;
> denominator = 1;
> goto out;
> }
>
> + /*
> + * Global reclaim will swap to prevent OOM even with no
> + * swappiness, but memcg users want to use this knob to
> + * disable swapping for individual groups completely when
> + * using the memory controller's swap limit feature would be
> + * too expensive.
> + */
> + if (!global_reclaim(sc) && !vmscan_swappiness(sc)) {
> + fraction[0] = 0;
> + fraction[1] = 1;
> + denominator = 1;
> + goto out;
> + }
> +
> + /*
> + * Do not apply any pressure balancing cleverness when the
> + * system is close to OOM, scan both anon and file equally
> + * (unless the swappiness setting disagrees with swapping).
> + */
> + if (!sc->priority && vmscan_swappiness(sc)) {
> + fraction[0] = 1;
> + fraction[1] = 1;
> + denominator = 1;
> + goto out;
> + }
> +
> anon = get_lru_size(lruvec, LRU_ACTIVE_ANON) +
> get_lru_size(lruvec, LRU_INACTIVE_ANON);
> file = get_lru_size(lruvec, LRU_ACTIVE_FILE) +
> @@ -1753,13 +1777,10 @@ static void get_scan_count(struct lruvec *lruvec,
> struct scan_control *sc,
> unsigned long scan;
>
> size = get_lru_size(lruvec, lru);
> - if (sc->priority || noswap || !vmscan_swappiness(sc)) {
> - scan = size >> sc->priority;
> - if (!scan && force_scan)
> - scan = min(size, SWAP_CLUSTER_MAX);
> - scan = div64_u64(scan * fraction[file], denominator);
> - } else
> - scan = size;
> + scan = size >> sc->priority;
> + if (!scan && force_scan)
> + scan = min(size, SWAP_CLUSTER_MAX);
> + scan = div64_u64(scan * fraction[file], denominator);
> nr[lru] = scan;
> }
> }
> --
> 1.7.11.7
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, Dec 17, 2012 at 11:57:01AM -0800, Joe Perches wrote:
> It'd be better to change the pr_cont uses to pr_emerg
>
> []
>
> > +static void decode_mc2_mce(struct mce *m)
> > +{
> > + u16 ec = EC(m->status);
> > + u8 xec = XEC(m->status, xec_mask);
> > +
> > + pr_emerg(HW_ERR "MC2 Error: ");
>
> Remove this and
>
> > + if (fam_ops->mc2_mce(ec, xec))
> > + ;
> > + else
> > + pr_emerg(HW_ERR "Corrupted MC2 MCE info?\n");
> > }
>
> And make this
>
> if (!fam_ops->mc2_mce(ec, xec))
> pr_emerg(etc...);
No, this is not how we do this here. We do pr_emerg in the main per-bank
function, i.e. mc0, mc1, mc2... and we finish the line in the respective
function with pr_cont.
If your fear is line interleaving, then this shouldn't happen in most
cases because we're in atomic #MC context and nothing else is executing
in that case. (And I haven't seen it interleave in all my testing so
far).
If it does interleave when we have a non-critical error detected and
reported in process context, then this whole decoding code needs a lot
more work than this.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/12] blkcg: make blkcg_gq's hierarchical
On Fri, Dec 14, 2012 at 02:41:17PM -0800, Tejun Heo wrote:
> Currently a child blkg (blkcg_gq) can be created even if its parent
> doesn't exist. ie. Given a blkg, it's not guaranteed that its
> ancestors will exist. This makes it difficult to implement proper
> hierarchy support for blkcg policies.
>
> Always create blkgs recursively and make a child blkg hold a reference
> to its parent. blkg->parent is added so that finding the parent is
> easy. blkcg_parent() is also added in the process.
>
> This change can be visible to userland. e.g. while issuing IO in a
> nested cgroup didn't affect the ancestors at all, now it will
> initialize all ancestor blkgs and zero stats for the request_queue
> will always appear on them. While this is userland visible, this
> shouldn't cause any functional difference.
>
> Signed-off-by: Tejun Heo
Looks good to me.
Acked-by: Vivek Goyal
Vivek
> ---
> block/blk-cgroup.c | 42 +-
> block/blk-cgroup.h | 18 ++
> 2 files changed, 55 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index fde2286..c858628 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -201,7 +201,16 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
> }
> blkg = new_blkg;
>
> - /* insert */
> + /* link parent and insert */
> + if (blkcg_parent(blkcg)) {
> + blkg->parent = __blkg_lookup(blkcg_parent(blkcg), q, false);
> + if (WARN_ON_ONCE(!blkg->parent)) {
> + blkg = ERR_PTR(-EINVAL);
> + goto err_put_css;
> + }
> + blkg_get(blkg->parent);
> + }
> +
> spin_lock(>lock);
> ret = radix_tree_insert(>blkg_tree, q->id, blkg);
> if (likely(!ret)) {
> @@ -213,6 +222,10 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
> if (!ret)
> return blkg;
>
> + /* @blkg failed fully initialized, use the usual release path */
> + blkg_put(blkg);
> + return ERR_PTR(ret);
> +
> err_put_css:
> css_put(>css);
> err_free_blkg:
> @@ -226,8 +239,9 @@ err_free_blkg:
> * @q: request_queue of interest
> *
> * Lookup blkg for the @blkcg - @q pair. If it doesn't exist, try to
> - * create one. This function should be called under RCU read lock and
> - * @q->queue_lock.
> + * create one. blkg creation is performed recursively from blkcg_root such
> + * that all non-root blkg's have access to the parent blkg. This function
> + * should be called under RCU read lock and @q->queue_lock.
> *
> * Returns pointer to the looked up or created blkg on success, ERR_PTR()
> * value on error. If @q is dead, returns ERR_PTR(-EINVAL). If @q is not
> @@ -252,7 +266,23 @@ struct blkcg_gq *blkg_lookup_create(struct blkcg *blkcg,
> if (blkg)
> return blkg;
>
> - return blkg_create(blkcg, q, NULL);
> + /*
> + * Create blkgs walking down from blkcg_root to @blkcg, so that all
> + * non-root blkgs have access to their parents.
> + */
> + while (true) {
> + struct blkcg *pos = blkcg;
> + struct blkcg *parent = blkcg_parent(blkcg);
> +
> + while (parent && !__blkg_lookup(parent, q, false)) {
> + pos = parent;
> + parent = blkcg_parent(parent);
> + }
> +
> + blkg = blkg_create(pos, q, NULL);
> + if (pos == blkcg || IS_ERR(blkg))
> + return blkg;
> + }
> }
> EXPORT_SYMBOL_GPL(blkg_lookup_create);
>
> @@ -321,8 +351,10 @@ static void blkg_rcu_free(struct rcu_head *rcu_head)
>
> void __blkg_release(struct blkcg_gq *blkg)
> {
> - /* release the extra blkcg reference this blkg has been holding */
> + /* release the blkcg and parent blkg refs this blkg has been holding */
> css_put(>blkcg->css);
> + if (blkg->parent)
> + blkg_put(blkg->parent);
>
> /*
>* A group is freed in rcu manner. But having an rcu lock does not
> diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
> index 2459730..b26ed58 100644
> --- a/block/blk-cgroup.h
> +++ b/block/blk-cgroup.h
> @@ -94,8 +94,13 @@ struct blkcg_gq {
> struct list_headq_node;
> struct hlist_node blkcg_node;
> struct blkcg*blkcg;
> +
> + /* all non-root blkcg_gq's are guaranteed to have access to parent */
> + struct blkcg_gq *parent;
> +
> /* request allocation list for this blkcg-q pair */
> struct request_list rl;
> +
> /* reference count */
> int refcnt;
>
> @@ -181,6 +186,19 @@ static inline struct blkcg *bio_blkcg(struct bio *bio)
> }
>
> /**
> + * blkcg_parent - get the parent of a blkcg
> + * @blkcg: blkcg of interest
> + *
> + * Return the parent blkcg of @blkcg. Can be called anytime.
>
Re: [patch 2/8] mm: vmscan: disregard swappiness shortly before going OOM
On Mon 17-12-12 12:54:15, Johannes Weiner wrote:
> On Mon, Dec 17, 2012 at 05:37:35PM +0100, Michal Hocko wrote:
> > On Fri 14-12-12 19:18:51, Johannes Weiner wrote:
> > > On Fri, Dec 14, 2012 at 05:13:45PM +0100, Michal Hocko wrote:
> > > > On Fri 14-12-12 10:43:55, Rik van Riel wrote:
> > > > > On 12/14/2012 03:37 AM, Michal Hocko wrote:
> > > > >
> > > > > >I can answer the later. Because memsw comes with its price and
> > > > > >swappiness is much cheaper. On the other hand it makes sense that
> > > > > >swappiness==0 doesn't swap at all. Or do you think we should get
> > > > > >back to
> > > > > >_almost_ doesn't swap at all?
> > > > >
> > > > > swappiness==0 will swap in emergencies, specifically when we have
> > > > > almost no page cache left, we will still swap things out:
> > > > >
> > > > > if (global_reclaim(sc)) {
> > > > > free = zone_page_state(zone, NR_FREE_PAGES);
> > > > > if (unlikely(file + free <= high_wmark_pages(zone))) {
> > > > > /*
> > > > > * If we have very few page cache pages,
> > > > > force-scan
> > > > > * anon pages.
> > > > > */
> > > > > fraction[0] = 1;
> > > > > fraction[1] = 0;
> > > > > denominator = 1;
> > > > > goto out;
> > > > >
> > > > > This makes sense, because people who set swappiness==0 but
> > > > > do have swap space available would probably prefer some
> > > > > emergency swapping over an OOM kill.
> > > >
> > > > Yes, but this is the global reclaim path. I was arguing about
> > > > swappiness==0 & memcg. As this patch doesn't make a big difference for
> > > > the global case (as both the changelog and you mentioned) then we should
> > > > focus on whether this is desirable change for the memcg path. I think it
> > > > makes sense to keep "no swapping at all for memcg semantic" as we have
> > > > it currently.
> > >
> > > I would prefer we could agree on one thing, though. Having global
> > > reclaim behave different from memcg reclaim violates the principle of
> > > least surprise.
> >
> > Hmm, I think that no swapping at all with swappiness==0 makes some sense
> > with the global reclaim as well. Why should we swap if admin told us not
> > to do that?
> > I am not so strong in that though because the global swappiness has been
> > more relaxed in the past and people got used to that. We have seen bug
> > reports already where users were surprised by a high io wait times when
> > it turned out that they had swappiness set to 0 because that prevented
> > swapping most of the time in the past but fe35004f changed that.
> >
> > Usecases for memcg are more natural because memcg allows much better
> > control over OOM and also requirements for (not) swapping are per group
> > rather than on swap availability. We shouldn't push users into using
> > memcg swap accounting to accomplish the same IMHO because the accounting
> > has some costs and its primary usage is not to disable swapping but
> > rather to keep it on the leash. The two approaches are also different
> > from semantic point of view. Swappiness is proportional while the limit
> > is an absolute number.
>
> I agree with the usecase that Rik described, though: it makes sense to
> go for file cache exclusively as long as the VM can make progress, but
> once we are getting close to OOM, we may as well swap. swappiness is
> describing an eagerness to swap, not a limit. Not swapping ever with
> !swappiness does not allow you to do this, even with very low
> swappiness settings, you can end up swapping with just little VM load.
>
> They way swappiness works for memcg gives you TWO options to prevent
> swapping entirely for individual groups, but no option to swap only in
> case of emergency, which I think is the broader usecase.
I think this is for a longer discussion.
> But I also won't fight this in this last-minute submission so I
> dropped this change of behaviour for now, it'll just be a cleanup.
Yes, this is reasonable. This is in no way a cleanup so it would just
delay otherwise very nice cleanup.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
On Mon, 2012-12-17 at 13:39 -0600, Jacob Shin wrote:
> Currently only AMD Family 15h processors have special handling for MC2
> errors, since upcoming Family 16h will also need unique handling,
> let's make MC2 handling part of amd_decoder_ops.
[]
> diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
[]
> @@ -399,12 +399,9 @@ static void decode_mc1_mce(struct mce *m)
> pr_emerg(HW_ERR "Corrupted MC1 MCE info?\n");
> }
>
> -static void decode_mc2_mce(struct mce *m)
> +static bool k8_mc2_mce(u16 ec, u8 xec)
> {
> - u16 ec = EC(m->status);
> - u8 xec = XEC(m->status, xec_mask);
> -
> - pr_emerg(HW_ERR "MC2 Error");
> + bool ret = true;
>
> if (xec == 0x1)
> pr_cont(" in the write data buffers.\n");
It'd be better to change the pr_cont uses to pr_emerg
[]
> +static void decode_mc2_mce(struct mce *m)
> +{
> + u16 ec = EC(m->status);
> + u8 xec = XEC(m->status, xec_mask);
> +
> + pr_emerg(HW_ERR "MC2 Error: ");
Remove this and
> + if (fam_ops->mc2_mce(ec, xec))
> + ;
> + else
> + pr_emerg(HW_ERR "Corrupted MC2 MCE info?\n");
> }
And make this
if (!fam_ops->mc2_mce(ec, xec))
pr_emerg(etc...);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ODROID-X: dts: Add mshc node for ODROID-X board
Adding the device node to support eMMC storage on SDCARD4 ports, controlled by
Mobile Storage Host Controller.
Signed-off-by: Dongjin Kim
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 3943011..fbd0b51 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -73,4 +73,25 @@
linux,default-trigger = "mmc0";
};
};
+
+ mshc@1255 {
+ num-slots = <1>;
+ supports-highspeed;
+ broken-cd;
+ fifo-depth = <0x80>;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3 3>;
+ samsung,dw-mshc-ddr-timing = <1 2 3>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ gpios = < 0 3>, < 1 3>,
+ < 3 3>, < 4 3>,
+ < 5 3>, < 6 3>,
+ < 3 4>, < 4 4>,
+ < 5 4>, < 6 4>;
+ };
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ODROID-X: dts: Add fixed-regulator for peripherals.
This patch adds the node to support fixed voltage for peripherals like LED,
ethernet controller.
Signed-off-by: Dongjin Kim
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 786ddd7..2d45dcb 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -49,4 +49,14 @@
pinctrl-names = "default";
status = "okay";
};
+
+ regulator_p3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "p3v3_en";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 1 0>;
+ enable-active-high;
+ regulator-boot-on;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ODROID-X: dts: Add nodes for leds based on GPIO.
This patch adds GPIO connected LEDS on ODROID-X board, and describe its
properties.
Signed-off-by: Dongjin Kim
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 2d45dcb..3943011 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -59,4 +59,18 @@
enable-active-high;
regulator-boot-on;
};
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ label = "led1:heart";
+ gpios = < 0 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ led2 {
+ label = "led2:mmc0";
+ gpios = < 2 0>;
+ linux,default-trigger = "mmc0";
+ };
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] ODROID-X: dts: Add board dts file for ODROID-X
Add initial dtb file for Hardkernel's ODROID-X board based on EXYNOS4412 SoC.
Signed-off-by: Dongjin Kim
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos4412-odroidx.dts | 52 ++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ca6fb8e..3355af9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -45,6 +45,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5440-ssdk5440.dtb \
exynos4412-smdk4412.dtb \
+ exynos4412-odroidx.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
new file mode 100644
index 000..786ddd7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -0,0 +1,52 @@
+/*
+ * Hardkernel's Exynos4412 based ODROID-X board device tree source
+ *
+ * Copyright (c) 2012-2013 Dongjin Kim
+ *
+ * Device tree source file for Hardkernel's ODROID-X board which is based on
+ * Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ "exynos4412.dtsi"
+
+/ {
+ model = "Hardkernel ODROID-X board based on Exynos4412";
+ compatible = "samsung,exynos4412";
+
+ memory {
+ reg = <0x4000 0x4000>;
+ };
+
+ chosen {
+ bootargs ="root=/dev/mmcblk0p3 rw console=ttySAC1,115200
init=/sbin/init delay=2";
+ };
+
+ serial@1380 {
+ status = "okay";
+ };
+
+ serial@1381 {
+ status = "okay";
+ };
+
+ serial@1382 {
+ status = "okay";
+ };
+
+ serial@1383 {
+ status = "okay";
+ };
+
+ sdhci@1253 {
+ bus-width = <4>;
+ samsung,cd-pinmux-gpio = < 2 2 3 3>;
+ pinctrl-0 = <_clk _cmd _bus4>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
On Mon 17-12-12 19:23:01, azurIt wrote: > >[Ohh, I am really an idiot. I screwed the first patch] > >- bool oom = true; > >+ bool oom = !(gfp_mask | GFP_MEMCG_NO_OOM); > > > >Which obviously doesn't work. It should read !(gfp_mask _MEMCG_NO_OOM). > > No idea how I could have missed that. I am really sorry about that. > > > :D no problem :) so, now it should really work as expected and > completely fix my original problem? It should mitigate the problem. The real fix shouldn't be that specific (as per discussion in other thread). The chance this will get upstream is not big and that means that it will not get to the stable tree either. > is it safe to apply it on 3.2.35? I didn't check what are the differences but I do not think there is anything to conflict with it. > Thank you very much! HTH -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources
To read reset sources registers we have to use PRM_DEVICE_INST --- arch/arm/mach-omap2/prm44xx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 7498bc7..0b61b8d 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -333,7 +333,7 @@ static u32 omap44xx_prm_read_reset_sources(void) u32 r = 0; u32 v; - v = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST, + v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, OMAP4_RM_RSTST); p = omap44xx_prm_reset_src_map; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: OMAP4: PRM: Correct PRM_RSTST and PRM_RSTTIME registers shifts
According to TRMs the assigned shifts are wrong, so correct them. --- arch/arm/mach-omap2/prm44xx.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 22b0979..8ee1fbd 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -62,8 +62,8 @@ /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST0x0004 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 0/6 v10] gpio: Add block GPIO
On 12/17/2012 07:02 PM, Roland Stigge wrote:
> On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
>> /* Do synchronous data output with a single write access */
>> __raw_writel(~mask, pio + PIO_OWDR);
>> __raw_writel(mask, pio + PIO_OWER);
>> __raw_writel(val, pio + PIO_ODSR);
>>
>> For caching we would need a storage. Not sure if it's worth compared to
>> a context switch into the kernel.
>
> Block GPIO is not only for you in userspace. ;-) You can also implement
> efficient n-bit bus I/O in kernel drivers, n-bit-banging. :-) So not
> always context switches involved.
OK, what do you think about the following untested patch:
>From b44cad16cbbca84715dffd4cb5268497216add25 Mon Sep 17 00:00:00 2001
From: Wolfgang Grandegger
Date: Mon, 3 Dec 2012 08:31:55 +0100
Subject: [PATCH 1/2] gpio: add GPIO block callback functions for AT91
Signed-off-by: Wolfgang Grandegger
---
arch/arm/mach-at91/gpio.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index be42cf0..cf6bd45 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -42,13 +42,16 @@ struct at91_gpio_chip {
void __iomem*regbase; /* PIO bank virtual address */
struct clk *clock; /* associated clock */
struct irq_domain *domain;/* associated irq domain */
+ unsigned long mask_shadow;/* synchronous data output */
};
#define to_at91_gpio_chip(c) container_of(c, struct at91_gpio_chip, chip)
static void at91_gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip);
static void at91_gpiolib_set(struct gpio_chip *chip, unsigned offset, int val);
+static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long mask,
unsigned long val);
static int at91_gpiolib_get(struct gpio_chip *chip, unsigned offset);
+static unsigned long at91_gpiolib_get_block(struct gpio_chip *chip, unsigned
long mask);
static int at91_gpiolib_direction_output(struct gpio_chip *chip,
unsigned offset, int val);
static int at91_gpiolib_direction_input(struct gpio_chip *chip,
@@ -62,7 +65,9 @@ static int at91_gpiolib_to_irq(struct gpio_chip *chip,
unsigned offset);
.direction_input = at91_gpiolib_direction_input, \
.direction_output = at91_gpiolib_direction_output, \
.get = at91_gpiolib_get, \
+ .get_block= at91_gpiolib_get_block, \
.set = at91_gpiolib_set, \
+ .set_block= at91_gpiolib_set_block, \
.dbg_show = at91_gpiolib_dbg_show, \
.to_irq = at91_gpiolib_to_irq,\
.ngpio= nr_gpio,\
@@ -896,6 +901,16 @@ static int at91_gpiolib_get(struct gpio_chip *chip,
unsigned offset)
return (pdsr & mask) != 0;
}
+static unsigned long at91_gpiolib_get_block(struct gpio_chip *chip, unsigned
long mask)
+{
+ struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
+ void __iomem *pio = at91_gpio->regbase;
+ u32 pdsr;
+
+ pdsr = __raw_readl(pio + PIO_PDSR);
+ return pdsr & mask;
+}
+
static void at91_gpiolib_set(struct gpio_chip *chip, unsigned offset, int val)
{
struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
@@ -905,6 +920,20 @@ static void at91_gpiolib_set(struct gpio_chip *chip,
unsigned offset, int val)
__raw_writel(mask, pio + (val ? PIO_SODR : PIO_CODR));
}
+static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long mask,
unsigned long val)
+{
+ struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
+ void __iomem *pio = at91_gpio->regbase;
+
+ /* Do synchronous data output with a single write access */
+ if (mask != at91_gpio->mask_shadow) {
+ at91_gpio->mask_shadow = mask;
+ __raw_writel(~mask, pio + PIO_OWDR);
+ __raw_writel(mask, pio + PIO_OWER);
+ }
+ __raw_writel(val, pio + PIO_ODSR);
+}
+
static void at91_gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip)
{
int i;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm: fix i8254 counter 0 wraparound
On Sat, Dec 15, 2012 at 06:34:37AM -0500, Nickolai Zeldovich wrote: > The kvm i8254 emulation for counter 0 (but not for counters 1 and 2) > has at least two bugs in mode 0: > > 1. The OUT bit, computed by pit_get_out(), is never set high. > > 2. The counter value, computed by pit_get_count(), wraps back around to >the initial counter value, rather than wrapping back to 0x >(which is the behavior described in the comment in __kpit_elapsed, >the behavior implemented by qemu, and the behavior observed on AMD >hardware). > > The bug stems from __kpit_elapsed computing the elapsed time mod the > initial counter value (stored as nanoseconds in ps->period). This is both > unnecessary (none of the callers of kpit_elapsed expect the value to be > at most the initial counter value) and incorrect (it causes pit_get_count > to appear to wrap around to the initial counter value rather than 0x). > Removing this mod from __kpit_elapsed fixes both of the above bugs. > > Signed-off-by: Nickolai Zeldovich > --- > arch/x86/kvm/i8254.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c > index 11300d2..c1d30b2 100644 > --- a/arch/x86/kvm/i8254.c > +++ b/arch/x86/kvm/i8254.c > @@ -122,7 +122,6 @@ static s64 __kpit_elapsed(struct kvm *kvm) >*/ > remaining = hrtimer_get_remaining(>timer); > elapsed = ps->period - ktime_to_ns(remaining); > - elapsed = mod_64(elapsed, ps->period); > > return elapsed; > } Reviewed-by: Marcelo Tosatti -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.6.9-rt21
On Mon, 17 Dec 2012, Mike Galbraith wrote: > On Mon, 2012-12-17 at 16:35 +0100, Thomas Gleixner wrote: > > Bah. This reverse user/kernel priority nonsense really should go away! > > Snort, I looked right at it too, looked perfectly fine :) The real bad news is, that I talked to someone about that reverse prio issue just a few hours before I committed that crime. Blergh! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: OMAP4: PRM: Correct PRM_RSTST and PRM_RSTTIME registers shifts
According to TRMs the assigned shifts are wrong, so correct them. --- arch/arm/mach-omap2/prm44xx.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 22b0979..8ee1fbd 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -62,8 +62,8 @@ /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST0x0004 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MCE, AMD: MCE decoding support for AMD Family 16h
Add MCE decoding logic for AMD Family 16h processors.
Signed-off-by: Jacob Shin
---
drivers/edac/mce_amd.c | 120 ++--
drivers/edac/mce_amd.h |6 +++
2 files changed, 122 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index 84320f9..7d2d037 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -64,6 +64,10 @@ EXPORT_SYMBOL_GPL(to_msgs);
const char * const ii_msgs[] = { "MEM", "RESV", "IO", "GEN" };
EXPORT_SYMBOL_GPL(ii_msgs);
+/* internal error type */
+const char * const uu_msgs[] = { "RESV", "RESV", "HWA", "RESV" };
+EXPORT_SYMBOL_GPL(uu_msgs);
+
static const char * const f15h_mc1_mce_desc[] = {
"UC during a demand linefill from L2",
"Parity error during data load from IC",
@@ -275,6 +279,23 @@ static bool f15h_mc0_mce(u16 ec, u8 xec)
return ret;
}
+static bool f16h_mc0_mce(u16 ec, u8 xec)
+{
+ u8 r4 = R4(ec);
+
+ if (MEM_ERROR(ec) && TT(ec) == TT_DATA && LL(ec) == LL_L1 &&
+ (r4 == R4_DRD || r4 == R4_DWR)) {
+
+ pr_cont("%s parity error due to %s.\n",
+ (xec == 0x0? "Data" : "Tag"),
+ (r4 == R4_DRD ? "load" : "store"));
+
+ return true;
+ }
+
+ return f14h_mc0_mce(ec, xec);
+}
+
static void decode_mc0_mce(struct mce *m)
{
u16 ec = EC(m->status);
@@ -379,6 +400,36 @@ static bool f15h_mc1_mce(u16 ec, u8 xec)
return ret;
}
+static bool f16h_mc1_mce(u16 ec, u8 xec)
+{
+ u8 r4= R4(ec);
+ bool ret = true;
+
+ if (MEM_ERROR(ec)) {
+ if (TT(ec) != TT_INSTR)
+ ret = false;
+
+ else if (r4 == R4_IRD)
+ pr_cont("%s array parity error for a tag hit.\n",
+ (xec == 0x0 ? "Data" : "Tag"));
+
+ else if (r4 == R4_SNOOP)
+ pr_cont("Tag error during snoop/victimization.\n");
+
+ else if (xec == 0x0)
+ pr_cont("Tag parity error from victim castout.\n");
+
+ else if (xec == 0x2)
+ pr_cont("Microcode patch RAM parity error.\n");
+
+ else
+ ret = false;
+ } else
+ ret = false;
+
+ return ret;
+}
+
static void decode_mc1_mce(struct mce *m)
{
u16 ec = EC(m->status);
@@ -469,6 +520,48 @@ static bool f15h_mc2_mce(u16 ec, u8 xec)
return ret;
}
+static bool f16h_mc2_mce(u16 ec, u8 xec)
+{
+ u8 r4= R4(ec);
+ bool ret = true;
+
+ if (MEM_ERROR(ec) && TT(ec) == TT_GEN && LL(ec) == LL_L2) {
+ switch (xec) {
+ case 0x04 ... 0x05:
+ pr_cont("Parity error in %s.\n",
+ (r4 == R4_RD ? "IBUFF" : "OBUFF"));
+ break;
+
+ case 0x09 ... 0x0b:
+ case 0x0d ... 0x0f:
+ pr_cont("ECC error in L2 tag (%s).\n",
+ (r4 == R4_GEN ? "BankReq" :
+ (r4 == R4_SNOOP ? "Probe" : "Fill")));
+ break;
+
+ case 0x10 ... 0x1b:
+ pr_cont("ECC error in L2 data array (%s).\n",
+ (r4 == R4_RD? "Hit" :
+ (r4 == R4_GEN ? "Attr" :
+ (r4 == R4_EVICT ? "Vict" : "Fill";
+ break;
+
+ case 0x1c ... 0x1f:
+ pr_cont("Parity error in L2 attribute bits (%s).\n",
+ (r4 == R4_RD ? "Hit" :
+ (r4 == R4_GEN ? "Attr" : "Fill")));
+ break;
+
+ default:
+ ret = false;
+ break;
+ }
+ } else
+ ret = false;
+
+ return ret;
+}
+
static void decode_mc2_mce(struct mce *m)
{
u16 ec = EC(m->status);
@@ -548,7 +641,7 @@ static void decode_mc4_mce(struct mce *m)
return;
case 0x19:
- if (boot_cpu_data.x86 == 0x15)
+ if (boot_cpu_data.x86 == 0x15 || boot_cpu_data.x86 == 0x16)
pr_cont("Compute Unit Data Error.\n");
else
goto wrong_mc4_mce;
@@ -634,6 +727,10 @@ static void decode_mc6_mce(struct mce *m)
static inline void amd_decode_err_code(u16 ec)
{
+ if (INT_ERROR(ec)) {
+ pr_emerg(HW_ERR "internal: %s\n", LL_MSG(ec));
+ return;
+ }
pr_emerg(HW_ERR "cache level: %s", LL_MSG(ec));
@@ -738,10 +835,18 @@ int amd_decode_mce(struct notifier_block *nb, unsigned
long val, void *data)
((m->status & MCI_STATUS_PCC) ? "PCC" : "-"),
((m->status & MCI_STATUS_ADDRV) ? "AddrV" : "-"));
-
[PATCH 1/2] MCE, AMD: Make MC2 decoding part of amd_decoder_ops as well
Currently only AMD Family 15h processors have special handling for MC2
errors, since upcoming Family 16h will also need unique handling,
let's make MC2 handling part of amd_decoder_ops.
Signed-off-by: Jacob Shin
---
drivers/edac/mce_amd.c | 58 ++--
drivers/edac/mce_amd.h |1 +
2 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index ad63757..84320f9 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -399,12 +399,9 @@ static void decode_mc1_mce(struct mce *m)
pr_emerg(HW_ERR "Corrupted MC1 MCE info?\n");
}
-static void decode_mc2_mce(struct mce *m)
+static bool k8_mc2_mce(u16 ec, u8 xec)
{
- u16 ec = EC(m->status);
- u8 xec = XEC(m->status, xec_mask);
-
- pr_emerg(HW_ERR "MC2 Error");
+ bool ret = true;
if (xec == 0x1)
pr_cont(" in the write data buffers.\n");
@@ -429,24 +426,18 @@ static void decode_mc2_mce(struct mce *m)
pr_cont(": %s parity/ECC error during data "
"access from L2.\n", R4_MSG(ec));
else
- goto wrong_mc2_mce;
+ ret = false;
} else
- goto wrong_mc2_mce;
+ ret = false;
} else
- goto wrong_mc2_mce;
-
- return;
+ ret = false;
- wrong_mc2_mce:
- pr_emerg(HW_ERR "Corrupted MC2 MCE info?\n");
+ return ret;
}
-static void decode_f15_mc2_mce(struct mce *m)
+static bool f15h_mc2_mce(u16 ec, u8 xec)
{
- u16 ec = EC(m->status);
- u8 xec = XEC(m->status, xec_mask);
-
- pr_emerg(HW_ERR "MC2 Error: ");
+ bool ret = true;
if (TLB_ERROR(ec)) {
if (xec == 0x0)
@@ -454,10 +445,10 @@ static void decode_f15_mc2_mce(struct mce *m)
else if (xec == 0x1)
pr_cont("Poison data provided for TLB fill.\n");
else
- goto wrong_f15_mc2_mce;
+ ret = false;
} else if (BUS_ERROR(ec)) {
if (xec > 2)
- goto wrong_f15_mc2_mce;
+ ret = false;
pr_cont("Error during attempted NB data read.\n");
} else if (MEM_ERROR(ec)) {
@@ -471,14 +462,24 @@ static void decode_f15_mc2_mce(struct mce *m)
break;
default:
- goto wrong_f15_mc2_mce;
+ ret = false;
}
}
- return;
+ return ret;
+}
- wrong_f15_mc2_mce:
- pr_emerg(HW_ERR "Corrupted MC2 MCE info?\n");
+static void decode_mc2_mce(struct mce *m)
+{
+ u16 ec = EC(m->status);
+ u8 xec = XEC(m->status, xec_mask);
+
+ pr_emerg(HW_ERR "MC2 Error: ");
+
+ if (fam_ops->mc2_mce(ec, xec))
+ ;
+ else
+ pr_emerg(HW_ERR "Corrupted MC2 MCE info?\n");
}
static void decode_mc3_mce(struct mce *m)
@@ -702,10 +703,7 @@ int amd_decode_mce(struct notifier_block *nb, unsigned
long val, void *data)
break;
case 2:
- if (c->x86 == 0x15)
- decode_f15_mc2_mce(m);
- else
- decode_mc2_mce(m);
+ decode_mc2_mce(m);
break;
case 3:
@@ -783,33 +781,39 @@ static int __init mce_amd_init(void)
case 0xf:
fam_ops->mc0_mce = k8_mc0_mce;
fam_ops->mc1_mce = k8_mc1_mce;
+ fam_ops->mc2_mce = k8_mc2_mce;
break;
case 0x10:
fam_ops->mc0_mce = f10h_mc0_mce;
fam_ops->mc1_mce = k8_mc1_mce;
+ fam_ops->mc2_mce = k8_mc2_mce;
break;
case 0x11:
fam_ops->mc0_mce = k8_mc0_mce;
fam_ops->mc1_mce = k8_mc1_mce;
+ fam_ops->mc2_mce = k8_mc2_mce;
break;
case 0x12:
fam_ops->mc0_mce = f12h_mc0_mce;
fam_ops->mc1_mce = k8_mc1_mce;
+ fam_ops->mc2_mce = k8_mc2_mce;
break;
case 0x14:
nb_err_cpumask = 0x3;
fam_ops->mc0_mce = f14h_mc0_mce;
fam_ops->mc1_mce = f14h_mc1_mce;
+ fam_ops->mc2_mce = k8_mc2_mce;
break;
case 0x15:
xec_mask = 0x1f;
fam_ops->mc0_mce = f15h_mc0_mce;
fam_ops->mc1_mce = f15h_mc1_mce;
+ fam_ops->mc2_mce = f15h_mc2_mce;
break;
default:
diff --git a/drivers/edac/mce_amd.h b/drivers/edac/mce_amd.h
index 6796799..000f6e2 100644
--- a/drivers/edac/mce_amd.h
+++ b/drivers/edac/mce_amd.h
@@ -78,6 +78,7 @@ extern const char * const ii_msgs[];
struct
Re: [GIT PULL] core block IO bits for 3.8
On Mon, Dec 17, 2012 at 11:28 AM, Jens Axboe wrote:
> On 2012-12-17 20:27, Linus Torvalds wrote:
>> On Mon, Dec 17, 2012 at 11:06 AM, Jens Axboe wrote:
>>>
>>> Sigh, in that case, yes lets just revert it.
>>
>> So just to check - we're talking about commit 8fa72d234da9 ("bdi: add
>> a user-tunable cpu_list for the bdi flusher threads"). It reverts
>> cleanly, but I wanted to make sure we're all on the same page..
Page, heh.
> That is the one, revert at will :-)
>
> --
> Jens Axboe
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] blkcg: cosmetic updates to blkg_create()
On Fri, Dec 14, 2012 at 02:41:16PM -0800, Tejun Heo wrote:
> * Rename out_* labels to err_*.
>
> * Do ERR_PTR() conversion once in the error return path.
>
> This patch is cosmetic and to prepare for the hierarchy support.
>
> Signed-off-by: Tejun Heo
Acked-by: Vivek Goyal
Vivek
> ---
> block/blk-cgroup.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index ffbd237..fde2286 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -187,16 +187,16 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
>
> /* blkg holds a reference to blkcg */
> if (!css_tryget(>css)) {
> - blkg = ERR_PTR(-EINVAL);
> - goto out_free;
> + ret = -EINVAL;
> + goto err_free_blkg;
> }
>
> /* allocate */
> if (!new_blkg) {
> new_blkg = blkg_alloc(blkcg, q, GFP_ATOMIC);
> if (unlikely(!new_blkg)) {
> - blkg = ERR_PTR(-ENOMEM);
> - goto out_put;
> + ret = -ENOMEM;
> + goto err_put_css;
> }
> }
> blkg = new_blkg;
> @@ -213,12 +213,11 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
> if (!ret)
> return blkg;
>
> - blkg = ERR_PTR(ret);
> -out_put:
> +err_put_css:
> css_put(>css);
> -out_free:
> +err_free_blkg:
> blkg_free(new_blkg);
> - return blkg;
> + return ERR_PTR(ret);
> }
>
> /**
> --
> 1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.7.1
diff --git a/Makefile b/Makefile
index 540f7b2..fbf84a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 7
-SUBLEVEL = 0
+SUBLEVEL = 1
EXTRAVERSION =
NAME = Terrified Chipmunk
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 1460a5d..e28670f 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -434,7 +434,7 @@ void hpet_msi_unmask(struct irq_data *data)
/* unmask it */
cfg = hpet_readl(HPET_Tn_CFG(hdev->num));
- cfg |= HPET_TN_FSB;
+ cfg |= HPET_TN_ENABLE | HPET_TN_FSB;
hpet_writel(cfg, HPET_Tn_CFG(hdev->num));
}
@@ -445,7 +445,7 @@ void hpet_msi_mask(struct irq_data *data)
/* mask it */
cfg = hpet_readl(HPET_Tn_CFG(hdev->num));
- cfg &= ~HPET_TN_FSB;
+ cfg &= ~(HPET_TN_ENABLE | HPET_TN_FSB);
hpet_writel(cfg, HPET_Tn_CFG(hdev->num));
}
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 45e3e17..7efaeaa 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_ACPI_PROCFS_POWER
#include
@@ -95,6 +96,18 @@ enum {
ACPI_BATTERY_ALARM_PRESENT,
ACPI_BATTERY_XINFO_PRESENT,
ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY,
+ /* On Lenovo Thinkpad models from 2010 and 2011, the power unit
+ switches between mWh and mAh depending on whether the system
+ is running on battery or not. When mAh is the unit, most
+ reported values are incorrect and need to be adjusted by
+ 1/design_voltage. Verified on x201, t410, t410s, and x220.
+ Pre-2010 and 2012 models appear to always report in mWh and
+ are thus unaffected (tested with t42, t61, t500, x200, x300,
+ and x230). Also, in mid-2012 Lenovo issued a BIOS update for
+ the 2011 models that fixes the issue (tested on x220 with a
+ post-1.29 BIOS), but as of Nov. 2012, no such update is
+ available for the 2010 models. */
+ ACPI_BATTERY_QUIRK_THINKPAD_MAH,
};
struct acpi_battery {
@@ -438,6 +451,21 @@ static int acpi_battery_get_info(struct acpi_battery
*battery)
kfree(buffer.pointer);
if (test_bit(ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY, >flags))
battery->full_charge_capacity = battery->design_capacity;
+ if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH, >flags) &&
+ battery->power_unit && battery->design_voltage) {
+ battery->design_capacity = battery->design_capacity *
+ 1 / battery->design_voltage;
+ battery->full_charge_capacity = battery->full_charge_capacity *
+ 1 / battery->design_voltage;
+ battery->design_capacity_warning =
+ battery->design_capacity_warning *
+ 1 / battery->design_voltage;
+ /* Curiously, design_capacity_low, unlike the rest of them,
+ is correct. */
+ /* capacity_granularity_* equal 1 on the systems tested, so
+ it's impossible to tell if they would need an adjustment
+ or not if their values were higher. */
+ }
return result;
}
@@ -486,6 +514,11 @@ static int acpi_battery_get_state(struct acpi_battery
*battery)
&& battery->capacity_now >= 0 && battery->capacity_now <= 100)
battery->capacity_now = (battery->capacity_now *
battery->full_charge_capacity) / 100;
+ if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH, >flags) &&
+ battery->power_unit && battery->design_voltage) {
+ battery->capacity_now = battery->capacity_now *
+ 1 / battery->design_voltage;
+ }
return result;
}
@@ -595,6 +628,24 @@ static void sysfs_remove_battery(struct acpi_battery
*battery)
mutex_unlock(>sysfs_lock);
}
+static void find_battery(const struct dmi_header *dm, void *private)
+{
+ struct acpi_battery *battery = (struct acpi_battery *)private;
+ /* Note: the hardcoded offsets below have been extracted from
+ the source code of dmidecode. */
+ if (dm->type == DMI_ENTRY_PORTABLE_BATTERY && dm->length >= 8) {
+ const u8 *dmi_data = (const u8 *)(dm + 1);
+ int dmi_capacity = get_unaligned((const u16 *)(dmi_data + 6));
+ if (dm->length >= 18)
+ dmi_capacity *= dmi_data[17];
+ if (battery->design_capacity * battery->design_voltage / 1000
+ != dmi_capacity &&
+ battery->design_capacity * 10 == dmi_capacity)
+ set_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH,
+ >flags);
+ }
+}
+
/*
* According to the ACPI spec, some kinds of primary batteries can
* report percentage battery remaining capacity directly to OS.
@@
Linux 3.7.1
I'm announcing the release of the 3.7.1 kernel. All users of the 3.7 kernel series must upgrade. The updated 3.7.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.7.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/x86/kernel/hpet.c |4 - drivers/acpi/battery.c | 77 drivers/acpi/sleep.c|8 +++ drivers/acpi/video.c| 14 ++ drivers/acpi/video_detect.c |8 +++ drivers/clk/ux500/u8500_clk.c |2 drivers/hwmon/fam15h_power.c|4 + drivers/pnp/pnpacpi/core.c |3 + drivers/staging/bcm/InterfaceInit.c |3 - drivers/staging/bcm/InterfaceInit.h |2 drivers/staging/telephony/ixj.c | 24 +-- drivers/usb/class/cdc-acm.c | 38 + drivers/usb/host/ehci-q.c | 12 + drivers/usb/host/ehci-sched.c |4 - drivers/usb/host/ohci-q.c | 19 drivers/usb/host/xhci-pci.c |7 ++- drivers/usb/misc/Kconfig|1 drivers/usb/serial/cp210x.c |1 drivers/usb/serial/ftdi_sio.c |3 - drivers/usb/serial/ftdi_sio_ids.h |6 ++ drivers/usb/serial/option.c | 25 +++ drivers/usb/storage/Kconfig |2 kernel/rcutree.c| 15 +++ kernel/trace/ftrace.c |2 kernel/trace/ring_buffer.c | 16 ++- mm/dmapool.c| 31 +++--- tools/perf/builtin-test.c | 38 + 28 files changed, 277 insertions(+), 94 deletions(-) Alan Stern (2): USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue USB: EHCI: bugfix: urb->hcpriv should not be NULL Bjørn Mork (1): USB: option: blacklist network interface on Huawei E173 Boris Ostrovsky (1): x86,AMD: Power driver support for AMD's family 16h processors Dan Carpenter (2): telephony: ijx: buffer overflow in ixj_write_cid() ftrace: Clear bits properly in reset_iter_read() Dan Williams (1): cdc-acm: implement TIOCSSERIAL to avoid blocking close(2) Eric Dumazet (1): rcu: Fix batch-limit size problem Greg Kroah-Hartman (2): USB: mark uas driver as BROKEN Linux 3.7.1 Jan Beulich (1): x86: hpet: Fix masking of MSI interrupts Kamil Iskra (1): ACPI / battery: Correct battery capacity values on Thinkpads Kevin McKinney (1): Staging: bcm: Add two products and remove an existing product. Lan Tianyu (2): ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist. ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist Linus Walleij (1): clk: ux500: fix bit error Marek Szyprowski (1): mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Markus Becker (1): USB: cp210x: add Virtenio Preon32 device id Martin Teichmann (1): USB: ftdi_sio: Add support for Newport AGILIS motor drivers Peter Korsgaard (1): usb: ftdi_sio: fixup BeagleBone A5+ quirk Rafael J. Wysocki (1): ACPI / PNP: Do not crash due to stale pointer use during system resume Rene Buergel (1): ezusb: add dependency to USB Sarah Sharp (1): xhci: Extend Fresco Logic MSI quirk. Steven Rostedt (2): ring-buffer: Fix NULL pointer if rb_set_head_page() fails ring-buffer: Fix race between integrity check and readers Zhang Rui (1): ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000 Zheng Liu (1): perf test: fix a build error on builtin-test li.ru...@zte.com.cn (1): USB: add new zte 3g-dongle's pid to option.c signature.asc Description: Digital signature
Linux 3.6.11
I'm announcing the release of the 3.6.11 kernel. Note, this is the LAST kernel in the 3.6.y series, it is now end-of-life. Please move to the 3.7.y kernel series at this time. The updated 3.6.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.6.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/include/asm/hwcap.h|3 arch/arm/include/asm/vfpmacros.h| 12 +- arch/arm/vfp/vfpmodule.c|9 + arch/powerpc/platforms/pseries/eeh_driver.c | 35 -- arch/x86/kernel/hpet.c |4 drivers/acpi/battery.c | 77 ++ drivers/acpi/sleep.c|8 + drivers/acpi/video.c| 14 ++ drivers/acpi/video_detect.c |8 + drivers/block/floppy.c |5 drivers/edac/edac_mc.c | 14 ++ drivers/edac/i82975x_edac.c | 11 -- drivers/gpu/drm/i915/intel_bios.c | 11 -- drivers/gpu/drm/i915/intel_display.c| 11 ++ drivers/hwmon/fam15h_power.c|4 drivers/input/matrix-keymap.c |3 drivers/mmc/host/sh_mmcif.c |8 - drivers/net/bonding/bond_main.c |7 + drivers/net/bonding/bond_sysfs.c|2 drivers/net/ethernet/8390/ne.c |1 drivers/net/ethernet/sis/sis900.c |2 drivers/net/irda/sir_dev.c |2 drivers/net/usb/cdc_ncm.c | 22 +++- drivers/net/usb/ipheth.c|5 drivers/pci/bus.c |3 drivers/pci/pcie/aer/aerdrv_core.c | 20 ++- drivers/pnp/pnpacpi/core.c |3 drivers/staging/ipack/bridges/tpci200.c |2 drivers/usb/class/cdc-acm.c | 38 ++ drivers/usb/host/ehci-q.c | 12 -- drivers/usb/host/ehci-sched.c |4 drivers/usb/host/ohci-q.c | 19 +++ drivers/usb/host/xhci-pci.c |7 - drivers/usb/serial/cp210x.c |1 drivers/usb/serial/ftdi_sio.c |3 drivers/usb/serial/ftdi_sio_ids.h |6 + drivers/usb/serial/option.c | 25 drivers/usb/storage/Kconfig |2 include/linux/mempolicy.h | 16 -- kernel/rcutree.c| 15 +- kernel/trace/ftrace.c |2 kernel/trace/ring_buffer.c | 16 ++ kernel/workqueue.c |4 mm/dmapool.c| 31 + mm/mempolicy.c | 22 mm/shmem.c | 26 ++-- net/ipv4/icmp.c |3 net/ipv4/inet_diag.c| 154 ++-- net/ipv4/ip_fragment.c | 19 +-- net/ipv4/route.c|7 - net/ipv6/inet6_connection_sock.c|3 net/sctp/chunk.c| 20 ++- net/sctp/socket.c |4 sound/soc/Makefile |5 tools/perf/builtin-test.c | 38 ++ 56 files changed, 564 insertions(+), 246 deletions(-) Alan Cox (1): ne2000: add the right platform device Alan Stern (2): USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue USB: EHCI: bugfix: urb->hcpriv should not be NULL Alexander Shiyan (1): irda: sir_dev: Fix copy/paste typo Bjørn Mork (2): USB: option: blacklist network interface on Huawei E173 net: cdc_ncm: add Huawei devices Boris Ostrovsky (1): x86,AMD: Power driver support for AMD's family 16h processors Chris Ball (1): Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts" Dan Carpenter (1): ftrace: Clear bits properly in reset_iter_read() Dan Williams (1): cdc-acm: implement TIOCSSERIAL to avoid blocking close(2) Eric Dumazet (2): rcu: Fix batch-limit size problem ipv6: fix inet6_csk_update_pmtu() return value Florian Fainelli (1): Input: matrix-keymap - provide proper module license Francois Romieu (1): sis900: fix sis900_set_mode call parameters. Greg Kroah-Hartman (2): USB: mark uas driver as BROKEN Linux 3.6.11 Guennadi Liakhovetski (1): mmc: sh-mmcif: avoid oops on spurious interrupts (second try) Huang Ying (1): PCI/PM: Fix deadlock when unbinding device if parent in D3cold Jan Beulich (1): x86: hpet: Fix masking of MSI interrupts Jani Nikula (2):
[regression] cpuidle_get_cpu_driver livelocks idle system
The 3.7 kernel grinds to a halt on boot of a system with
2048 cpus. NMI showed most of the cpus in
_raw_spin_lock in cpuidle_get_cpu_driver(). (backtrace below)
A quick look at cpuidle_get_cpu_driver() shows the hot lock.
In drivers/cpuidle/driver.c:
/**
* cpuidle_get_cpu_driver - return the driver tied with a cpu
*/
struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
{
struct cpuidle_driver *drv;
if (!dev)
return NULL;
spin_lock(_driver_lock);
drv = __cpuidle_get_cpu_driver(dev->cpu);
spin_unlock(_driver_lock);
return drv;
}
This change was added in on Nov 14th, 2012.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92
The patch says it adds support for cpus with different characteristics,
but adds a big global lock. The comment claims "no impact for the other
platforms if the option is disabled", which leads me to believe the
spin_lock was added inadvertently. CPU_IDLE_MULTIPLE_DRIVERS is off
in my config file.
linux$ grep CPU_IDLE_MULTIPLE_DRIVERS .config
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
As more cpus become idle, more cpus fight over the lock until
the system livelocks on the crushing weight of idle.
The fix may be to move the spin_lock into __cpuidle_get_cpu_driver,
which has different versions for CONFIG_CPU_IDLE_MULTIPLE_DRIVERS,
to avoid impacting the disabled case, or get rid of the spin_lock
all together.
== UV NMI process trace cpu 12: ==
CPU 12
Pid: 0, comm: swapper/12 Tainted: G O 3.7.0.rja-sgi+ #38
RIP: 0010:[] [] _raw_spin_lock+0x25/0x30
[...]
Call Trace:
[] cpuidle_get_cpu_driver+0x1c/0x30
[] cpuidle_idle_call+0x7d/0x1b0
[] cpu_idle+0xdd/0x130
[] start_secondary+0xc6/0xcc
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.4.24
diff --git a/Makefile b/Makefile
index bf1df55..a3e12e6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 23
+SUBLEVEL = 24
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/arm/include/asm/hwcap.h b/arch/arm/include/asm/hwcap.h
index 9176261..a2fe893 100644
--- a/arch/arm/include/asm/hwcap.h
+++ b/arch/arm/include/asm/hwcap.h
@@ -18,11 +18,12 @@
#define HWCAP_THUMBEE (1 << 11)
#define HWCAP_NEON (1 << 12)
#define HWCAP_VFPv3(1 << 13)
-#define HWCAP_VFPv3D16 (1 << 14)
+#define HWCAP_VFPv3D16 (1 << 14) /* also set for VFPv4-D16 */
#define HWCAP_TLS (1 << 15)
#define HWCAP_VFPv4(1 << 16)
#define HWCAP_IDIVA(1 << 17)
#define HWCAP_IDIVT(1 << 18)
+#define HWCAP_VFPD32 (1 << 19) /* set if VFP has 32 regs (not 16) */
#define HWCAP_IDIV (HWCAP_IDIVA | HWCAP_IDIVT)
#if defined(__KERNEL__)
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index bf53047..c49c8f7 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -27,9 +27,9 @@
#if __LINUX_ARM_ARCH__ <= 6
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
- tst \tmp, #HWCAP_VFPv3D16
- ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
- addne \base, \base, #32*4 @ step over unused register
space
+ tst \tmp, #HWCAP_VFPD32
+ ldcnel p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ addeq \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
@@ -51,9 +51,9 @@
#if __LINUX_ARM_ARCH__ <= 6
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
- tst \tmp, #HWCAP_VFPv3D16
- stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
- addne \base, \base, #32*4 @ step over unused register
space
+ tst \tmp, #HWCAP_VFPD32
+ stcnel p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ addeq \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 1f8241d..3b36062 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -701,11 +701,14 @@ static int __init vfp_init(void)
elf_hwcap |= HWCAP_VFPv3;
/*
-* Check for VFPv3 D16. CPUs in this configuration
-* only have 16 x 64bit registers.
+* Check for VFPv3 D16 and VFPv4 D16. CPUs in
+* this configuration only have 16 x 64bit
+* registers.
*/
if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
- elf_hwcap |= HWCAP_VFPv3D16;
+ elf_hwcap |= HWCAP_VFPv3D16; /* also v4-D16 */
+ else
+ elf_hwcap |= HWCAP_VFPD32;
}
#endif
/*
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index ad0de0c..2861b4c 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -431,7 +431,7 @@ void hpet_msi_unmask(struct irq_data *data)
/* unmask it */
cfg = hpet_readl(HPET_Tn_CFG(hdev->num));
- cfg |= HPET_TN_FSB;
+ cfg |= HPET_TN_ENABLE | HPET_TN_FSB;
hpet_writel(cfg, HPET_Tn_CFG(hdev->num));
}
@@ -442,7 +442,7 @@ void hpet_msi_mask(struct irq_data *data)
/* mask it */
cfg = hpet_readl(HPET_Tn_CFG(hdev->num));
- cfg &= ~HPET_TN_FSB;
+ cfg &= ~(HPET_TN_ENABLE | HPET_TN_FSB);
hpet_writel(cfg, HPET_Tn_CFG(hdev->num));
}
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 7dd3f9f..6ea287e2 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_ACPI_PROCFS_POWER
#include
@@ -95,6 +96,18 @@ enum {
ACPI_BATTERY_ALARM_PRESENT,
ACPI_BATTERY_XINFO_PRESENT,
ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY,
+ /* On Lenovo Thinkpad models from 2010 and 2011, the power unit
+ switches between mWh and mAh depending on whether the system
+ is running on battery or not. When mAh is the unit, most
+ reported values are incorrect and need to be adjusted by
+ 1/design_voltage. Verified on x201, t410, t410s, and x220.
+ Pre-2010 and 2012
Linux 3.4.24
I'm announcing the release of the 3.4.24 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/include/asm/hwcap.h |3 - arch/arm/include/asm/vfpmacros.h | 12 ++--- arch/arm/vfp/vfpmodule.c |9 ++-- arch/x86/kernel/hpet.c |4 - drivers/acpi/battery.c | 77 +++ drivers/acpi/sleep.c |8 +++ drivers/acpi/video.c | 14 ++ drivers/gpu/drm/i915/intel_bios.c| 11 - drivers/gpu/drm/i915/intel_display.c | 11 + drivers/hwmon/fam15h_power.c |4 + drivers/mmc/host/sh_mmcif.c |8 --- drivers/pnp/pnpacpi/core.c |3 + drivers/staging/telephony/ixj.c | 24 +- drivers/usb/class/cdc-acm.c | 38 + drivers/usb/host/ohci-q.c| 19 drivers/usb/host/xhci-pci.c |7 ++- drivers/usb/serial/cp210x.c |1 drivers/usb/serial/ftdi_sio.c|3 - drivers/usb/serial/ftdi_sio_ids.h|6 ++ drivers/usb/serial/option.c | 25 +++ drivers/usb/storage/Kconfig |2 include/linux/mempolicy.h| 16 --- kernel/rcutree.c | 14 +++--- kernel/trace/ftrace.c|2 kernel/workqueue.c |4 - mm/dmapool.c | 31 +++--- mm/mempolicy.c | 22 -- mm/shmem.c | 26 +++ sound/soc/Makefile |5 +- tools/perf/builtin-test.c| 38 + 31 files changed, 295 insertions(+), 154 deletions(-) Alan Stern (1): USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue Bjørn Mork (1): USB: option: blacklist network interface on Huawei E173 Boris Ostrovsky (1): x86,AMD: Power driver support for AMD's family 16h processors Chris Ball (1): Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts" Dan Carpenter (2): telephony: ijx: buffer overflow in ixj_write_cid() ftrace: Clear bits properly in reset_iter_read() Dan Williams (1): cdc-acm: implement TIOCSSERIAL to avoid blocking close(2) Eric Dumazet (1): rcu: Fix batch-limit size problem Greg Kroah-Hartman (2): USB: mark uas driver as BROKEN Linux 3.4.24 Guennadi Liakhovetski (1): mmc: sh-mmcif: avoid oops on spurious interrupts (second try) Jan Beulich (1): x86: hpet: Fix masking of MSI interrupts Jani Nikula (2): drm/i915: do not ignore eDP bpc settings from vbt drm/i915: do not default to 18 bpp for eDP if missing from VBT Kamil Iskra (1): ACPI / battery: Correct battery capacity values on Thinkpads Lan Tianyu (1): ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist. Marek Szyprowski (1): mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Markus Becker (1): USB: cp210x: add Virtenio Preon32 device id Martin Teichmann (1): USB: ftdi_sio: Add support for Newport AGILIS motor drivers Mel Gorman (1): tmpfs: fix shared mempolicy leak Paul Walmsley (1): ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set Peter Korsgaard (1): usb: ftdi_sio: fixup BeagleBone A5+ quirk Peter Ujfalusi (1): ASoC: dmaengine: Correct Makefile when sound is built as module Rafael J. Wysocki (1): ACPI / PNP: Do not crash due to stale pointer use during system resume Sarah Sharp (1): xhci: Extend Fresco Logic MSI quirk. Tejun Heo (1): workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s Zhang Rui (1): ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000 Zheng Liu (1): perf test: fix a build error on builtin-test li.ru...@zte.com.cn (1): USB: add new zte 3g-dongle's pid to option.c signature.asc Description: Digital signature
Re: Linux 3.0.57
diff --git a/Makefile b/Makefile
index b639af3..cc6805f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 56
+SUBLEVEL = 57
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/arm/include/asm/hwcap.h b/arch/arm/include/asm/hwcap.h
index c1062c3..1e3f30f 100644
--- a/arch/arm/include/asm/hwcap.h
+++ b/arch/arm/include/asm/hwcap.h
@@ -18,8 +18,9 @@
#define HWCAP_THUMBEE 2048
#define HWCAP_NEON 4096
#define HWCAP_VFPv38192
-#define HWCAP_VFPv3D16 16384
+#define HWCAP_VFPv3D16 (1 << 14) /* also set for VFPv4-D16 */
#define HWCAP_TLS 32768
+#define HWCAP_VFPD32 (1 << 19) /* set if VFP has 32 regs (not 16) */
#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
/*
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index bf53047..c49c8f7 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -27,9 +27,9 @@
#if __LINUX_ARM_ARCH__ <= 6
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
- tst \tmp, #HWCAP_VFPv3D16
- ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
- addne \base, \base, #32*4 @ step over unused register
space
+ tst \tmp, #HWCAP_VFPD32
+ ldcnel p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
+ addeq \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
@@ -51,9 +51,9 @@
#if __LINUX_ARM_ARCH__ <= 6
ldr \tmp, =elf_hwcap@ may not have MVFR regs
ldr \tmp, [\tmp, #0]
- tst \tmp, #HWCAP_VFPv3D16
- stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
- addne \base, \base, #32*4 @ step over unused register
space
+ tst \tmp, #HWCAP_VFPD32
+ stcnel p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
+ addeq \base, \base, #32*4 @ step over unused register
space
#else
VFPFMRX \tmp, MVFR0 @ Media and VFP Feature
Register 0
and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index f25e7ec..ce18802 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -575,11 +575,14 @@ static int __init vfp_init(void)
elf_hwcap |= HWCAP_VFPv3;
/*
-* Check for VFPv3 D16. CPUs in this configuration
-* only have 16 x 64bit registers.
+* Check for VFPv3 D16 and VFPv4 D16. CPUs in
+* this configuration only have 16 x 64bit
+* registers.
*/
if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
- elf_hwcap |= HWCAP_VFPv3D16;
+ elf_hwcap |= HWCAP_VFPv3D16; /* also v4-D16 */
+ else
+ elf_hwcap |= HWCAP_VFPD32;
}
#endif
#ifdef CONFIG_NEON
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index cb22024..9321d0f 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1497,9 +1497,14 @@ long arch_ptrace(struct task_struct *child, long request,
if (index < PT_FPR0) {
tmp = ptrace_get_reg(child, (int) index);
} else {
+ unsigned int fpidx = index - PT_FPR0;
+
flush_fp_to_thread(child);
- tmp = ((unsigned long *)child->thread.fpr)
- [TS_FPRWIDTH * (index - PT_FPR0)];
+ if (fpidx < (PT_FPSCR - PT_FPR0))
+ tmp = ((unsigned long *)child->thread.fpr)
+ [fpidx * TS_FPRWIDTH];
+ else
+ tmp = child->thread.fpscr.val;
}
ret = put_user(tmp, datalp);
break;
@@ -1525,9 +1530,14 @@ long arch_ptrace(struct task_struct *child, long request,
if (index < PT_FPR0) {
ret = ptrace_put_reg(child, index, data);
} else {
+ unsigned int fpidx = index - PT_FPR0;
+
flush_fp_to_thread(child);
- ((unsigned long *)child->thread.fpr)
- [TS_FPRWIDTH * (index - PT_FPR0)] = data;
+ if (fpidx < (PT_FPSCR - PT_FPR0))
+ ((unsigned long *)child->thread.fpr)
+
