On 07/08/2013 06:05 AM, Rafael J. Wysocki wrote:
>
> That's because no one knows how to fix it. Actually, we don't even know
> what the root cause of it is. Sorry about that.
>
> Are you still able to make things work again by reverting the commit you
> bisected to?
>
Well, we know now. Hop
On 07/12/2013 04:36 PM, Christian Sünkenberg wrote:
>
> Jonas tried your patch and it fixes suspend/resume on his T43, although
> IMHO the safest approach would be to just add an exception for
> Vendor==Intel && Family==6 && Model==13, or more generally Vendor==Intel
> && !supports_long_mode, as t
Hello,
On 07/11/2013 01:57 AM, H. Peter Anvin wrote:
> On 07/10/2013 01:52 PM, Christian Sünkenberg wrote:
>> Hello,
>>
>> On 05/01/2013 07:33 PM, H. Peter Anvin wrote:
>>> On 05/01/2013 10:01 AM, Jonas Heinrich wrote:
Hello, I tried the newest kernel, 3.9 today but the bug is still
pres
On 07/10/2013 01:52 PM, Christian Sünkenberg wrote:
> Hello,
>
> On 05/01/2013 07:33 PM, H. Peter Anvin wrote:
>> On 05/01/2013 10:01 AM, Jonas Heinrich wrote:
>>> Hello, I tried the newest kernel, 3.9 today but the bug is still
>>> present. Applying the attached patch solves the bug for me.
>>>
>
Hello,
On 05/01/2013 07:33 PM, H. Peter Anvin wrote:
> On 05/01/2013 10:01 AM, Jonas Heinrich wrote:
>> Hello, I tried the newest kernel, 3.9 today but the bug is still
>> present. Applying the attached patch solves the bug for me.
>>
>> Best regards, Jonas Heinrich
>
> Okay... WTF is going on he
On Monday, July 08, 2013 09:50:43 AM Jonas Heinrich wrote:
> On 05-03 15:15, Jarkko Sakkinen wrote:
> > Hi
> >
> > On Friday, May 03, 2013 02:07:05 PM Jonas Heinrich wrote:
> > > On 05-03 01:29, Rafael J. Wysocki wrote:
> > > > On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> > > > >
On 05-03 15:15, Jarkko Sakkinen wrote:
> Hi
>
> On Friday, May 03, 2013 02:07:05 PM Jonas Heinrich wrote:
> > On 05-03 01:29, Rafael J. Wysocki wrote:
> > > On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> > > > On 05-02 02:45, Rafael J. Wysocki wrote:
> > > > > On Wednesday, May 01,
On Friday, May 03, 2013 01:37:45 PM Rafael J. Wysocki wrote:
> On Friday, May 03, 2013 11:07:05 AM Jonas Heinrich wrote:
> > On 05-03 01:29, Rafael J. Wysocki wrote:
> > > On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> > > > On 05-02 02:45, Rafael J. Wysocki wrote:
> > > > > On Wedne
Hi
On Friday, May 03, 2013 02:07:05 PM Jonas Heinrich wrote:
> On 05-03 01:29, Rafael J. Wysocki wrote:
> > On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> > > On 05-02 02:45, Rafael J. Wysocki wrote:
> > > > On Wednesday, May 01, 2013 11:55:10 AM H. Peter Anvin wrote:
> > > > > On 0
On Friday, May 03, 2013 11:07:05 AM Jonas Heinrich wrote:
> On 05-03 01:29, Rafael J. Wysocki wrote:
> > On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> > > On 05-02 02:45, Rafael J. Wysocki wrote:
> > > > On Wednesday, May 01, 2013 11:55:10 AM H. Peter Anvin wrote:
> > > > > On 05/01
On 05-03 01:29, Rafael J. Wysocki wrote:
> On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> > On 05-02 02:45, Rafael J. Wysocki wrote:
> > > On Wednesday, May 01, 2013 11:55:10 AM H. Peter Anvin wrote:
> > > > On 05/01/2013 11:51 AM, Jonas Heinrich wrote:
> > > > > Well, you could give
On Thursday, May 02, 2013 08:32:30 PM Jonas Heinrich wrote:
> On 05-02 02:45, Rafael J. Wysocki wrote:
> > On Wednesday, May 01, 2013 11:55:10 AM H. Peter Anvin wrote:
> > > On 05/01/2013 11:51 AM, Jonas Heinrich wrote:
> > > > Well, you could give me instructions on how to debug this (I'll do
> >
On 05-02 02:45, Rafael J. Wysocki wrote:
> On Wednesday, May 01, 2013 11:55:10 AM H. Peter Anvin wrote:
> > On 05/01/2013 11:51 AM, Jonas Heinrich wrote:
> > > Well, you could give me instructions on how to debug this (I'll do
> > > everything ;)) or I could ship you the Thinkpad T43. I guess this
On Wednesday, May 01, 2013 11:55:10 AM H. Peter Anvin wrote:
> On 05/01/2013 11:51 AM, Jonas Heinrich wrote:
> > Well, you could give me instructions on how to debug this (I'll do
> > everything ;)) or I could ship you the Thinkpad T43. I guess this
> > would worth the effort since this bug is som
On 05/01/2013 11:51 AM, Jonas Heinrich wrote:
> Well, you could give me instructions on how to debug this (I'll do
> everything ;)) or I could ship you the Thinkpad T43. I guess this
> would worth the effort since this bug is somehow critical.
>
> Best regards, Jonas
I'll put together a debug pa
Well, you could give me instructions on how to debug this (I'll do
everything ;)) or I could ship you the Thinkpad T43. I guess this would
worth the effort since this bug is somehow critical.
Best regards,
Jonas
On 05-01 10:33, H. Peter Anvin wrote:
> On 05/01/2013 10:01 AM, Jonas Heinrich wrote:
On 05/01/2013 10:01 AM, Jonas Heinrich wrote:
> Hello, I tried the newest kernel, 3.9 today but the bug is still
> present. Applying the attached patch solves the bug for me.
>
> Best regards, Jonas Heinrich
Okay... WTF is going on here? Does pmode_behavior just not get set up
correctly? Since
Hello,
I tried the newest kernel, 3.9 today but the bug is still present.
Applying the attached patch solves the bug for me.
Best regards,
Jonas Heinrich
On 03-20 14:32, Jonas Heinrich wrote:
> Hello Peter,
> sorry for responding that late to your advice ...
>
> On 02-23 13:54, H. Peter Anvin wr
On 02/23/2013 05:18 AM, Jonas Heinrich wrote:
Hi,
thank you for your replay and the effort you invest in helping me out
with this problem.
Today, I further debuged the problem and reverted this part of your commit
(without understanding the actual code):
Hi, that commit is indeed buggy, but it
Hi,
thank you for your replay and the effort you invest in helping me out
with this problem.
Today, I further debuged the problem and reverted this part of your commit
(without understanding the actual code):
diff --git a/arch/x86/realmode/rm/wakeup_asm.S
b/arch/x86/realmode/rm/wakeup_asm.S
index
I might be able to get my hands on a T43 later this week and see if I can
reproduce this. This patch seems more plausible, at least... but still
puzzling.
Jonas Heinrich wrote:
>On 02-17 21:40, Rafael J. Wysocki wrote:
>> Does the commit immediately preceding this one behave correctly?
>Stran
T43 is quite old... which might have exposed unique bugs. How reliable is the
failure? Even one misidentified commit results in git bisect giving garbage.
Jonas Heinrich wrote:
>Hello,
>since kernel version 3.7-rc1 I can't resume my notebook (Thinkpad T43)
>from suspend2ram
On Sunday, February 17, 2013 05:48:25 PM Jonas Heinrich wrote:
> Hello,
> since kernel version 3.7-rc1 I can't resume my notebook (Thinkpad T43)
> from suspend2ram anymore.
>
> I started a kernel bisection (see bisection_log in attachement). Also
> see kernel conifg
On 10/31/2012 07:44 PM, Steven Rostedt wrote:
On Wed, 2012-10-17 at 22:23 +0200, Arend van Spriel wrote:
Hi Steven,
I have nightly test machines upgraded to 3.7-rc1 and on the 64-bit
platform I get MODPOST warning on 'mcount'.
It is conditionally exported in x8664_ksyms_64
On Wed, 2012-10-17 at 22:23 +0200, Arend van Spriel wrote:
> Hi Steven,
>
> I have nightly test machines upgraded to 3.7-rc1 and on the 64-bit
> platform I get MODPOST warning on 'mcount'.
>
> It is conditionally exported in x8664_ksyms_64.c:
> #ifdef CONFIG
On Sun, 28 Oct 2012 11:04:46 +0100
Jiri Slaby wrote:
> On 10/02/2012 12:13 AM, Greg KH wrote:
> > On Mon, Oct 01, 2012 at 11:48:58PM +0200, Jiri Slaby wrote:
> >> On 10/01/2012 08:30 PM, Greg KH wrote:
> >>> Stanislav Kozina (2):
> >>> tty: Fix possible race in n_tty_read()
> >>
> >> The (p
On 10/02/2012 12:13 AM, Greg KH wrote:
> On Mon, Oct 01, 2012 at 11:48:58PM +0200, Jiri Slaby wrote:
>> On 10/01/2012 08:30 PM, Greg KH wrote:
>>> Stanislav Kozina (2):
>>> tty: Fix possible race in n_tty_read()
>>
>> The (pretty hopeless) commit log says:
>> Fix possible panic caused by
On Wed, Oct 03, 2012 at 09:31:02AM -0700, Tony Lindgren wrote:
> Actually we can also drop "#include " too,
> it's now empty for mach-omap2. I've updated Tim's patch below
> for you guys to queue via the ASoC fixes. It's against the
> current linux next.
Applied. Tim, you should send patches usi
On Thursday 25 of October 2012 20:06:54 Heinz Diehl wrote:
> On 25.10.2012, Paweł Sikora wrote:
>
> > what is the reason of loading nouveau driver for laptops
> > with nvidia optimus and enabling vga switcheroo
> > which doesn't work in such (optimus) cases.
>
> You can safely compile a kernel
On 25.10.2012, Paweł Sikora wrote:
> what is the reason of loading nouveau driver for laptops
> with nvidia optimus and enabling vga switcheroo
> which doesn't work in such (optimus) cases.
You can safely compile a kernel without nouveau, your Nvidia
card will not be used at all since neither
KiB
> >
> > fixes the problem.
>
> Can you test the attached patch too ? I rebased the previous one I sent
> on top on 3.7-rc1 as I accidentally used an older version.
>
> Martin
Hi all once again,
i've tested current 3.7.0-rc2-00145-g4864ccb and it works fine (boots a
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, October 22, 2012 7:34 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com
&
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2
linux-kernel@vger.kernel.org;
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > jasow...@redhat.com
> > Subject: Re: 3.7 RC1
> >
> > On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote:
> > >
> > > While testing
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, October 22, 2012 7:34 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com
&
nical.com;
> jasow...@redhat.com
> Subject: Re: 3.7 RC1
>
> On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote:
> >
> > While testing 3.7 RC1 I discovered that invoking the function
> orderly_poweroff()
> > from an interrupt context will trigger an ASSERT()
On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote:
>
> While testing 3.7 RC1 I discovered that invoking the function
> orderly_poweroff()
> from an interrupt context will trigger an ASSERT(). This was not the case till
> recently. The comment preceding the o
@canonical.com; jasow...@redhat.com
> Subject: Re: 3.7 RC1
>
> On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote:
> >
> > While testing 3.7 RC1 I discovered that invoking the function
> orderly_poweroff()
> > from an interrupt context will trigger an ASSERT()
On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote:
>
> While testing 3.7 RC1 I discovered that invoking the function
> orderly_poweroff()
> from an interrupt context will trigger an ASSERT(). This was not the case till
> recently. The comment preceding the o
now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] nouveau [
On Sunday 21 October 2012 16:49:08 Marcin Slusarz wrote:
> On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> >
> > wrote:
> > > This looks like ACPI bug...
> >
> > I'm shocked to hear that firmware would be fragile.
> >
> > Anywa
On Sun, Oct 21, 2012 at 5:49 PM, Marcin Slusarz
wrote:
>
> I know. But this bug is not about broken firmware. It's about Linux kernel
> ACPI implementation, which (I think) wrongly interprets ACPI script.
Hmm. Len, care to comment? Marcin quoted the AML and our arguments in
an earlier thing. I do
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote:
> On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
> wrote:
> >
> > This looks like ACPI bug...
>
> I'm _shocked_ to hear that firmware would be fragile.
>
> Anyway, here's the #1 thing to keep in mind about firmware:
>
> - firmwar
On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz
wrote:
>
> This looks like ACPI bug...
I'm _shocked_ to hear that firmware would be fragile.
Anyway, here's the #1 thing to keep in mind about firmware:
- firmware is *always* buggy.
It's that simple. Don't expect anything else. Firmware is writ
On 21.10.2012, Marcin Slusarz wrote:
> > > Please attach acpidump output.
> >
> > http://pluto.agmk.net/nv/acpidump.txt
> >
>
> This looks like ACPI bug...
I guess my acpidump didn't make it to the list. Anyway, here it is:
http://www.fritha.org/acpidump.gz
--
To unsubscribe from this list:
s one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
>
On 21.10.2012, Paweł Sikora wrote:
> with these both patches applied my laptop boots and gui works fine.
The same here. The two patches together, applied to 3.7-rc1 let my
machine boot again. Here's the relevant dmesg cut:
[3.702671] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x
On 21.10.2012, Marcin Slusarz wrote:
> On 3.6 kernel? (It doesn't exist on 3.7)
> Note that it may be in other directory than "0".
[root@wildsau linux-3.6.2]# cat .config | grep -i "nouveau"
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_NOUVEAU_DEBUG=y
I grepped the whole disk,
dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] nouveau [
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685
to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> >
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > minor 0
> > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > [3.689960] n
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685
On 20.10.2012, Marcin Slusarz wrote:
> Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[3.687784] nouveau [ DEV
On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote:
> >
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top
On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote:
>
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
>
> Yes, of course.
>
>
On 20.10.2012, Martin Peres wrote:
> Can you test the attached patch too ? I rebased the previous one I sent on
> top on 3.7-rc1 as I accidentally used an older version.
Yes, of course.
Tried it. Unfortunately, the crash remains the same as reported.
--
To unsubscribe from this list: se
thing going on. Reverting
Ben Skeggs
drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB
fixes the problem.
Can you test the attached patch too ? I rebased the previous one I sent
on top on 3.7-rc1 as I accidentally used an older version.
Martin
>F
On 20.10.2012, Linus Torvalds wrote:
> Added more appropriate people to this. Added both i915 and nouveau
> people, since apparently that fine piece of hardware has both.
>
> Guys, any ideas?
Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same
thing going on. Reverting
Ben Skeggs
On Fri, Oct 19, 2012 at 3:41 PM, Martin Peres wrote:
>
> You must have missed the oops that was attached to the mail:
> http://www.spinics.net/lists/kernel/msg1420355.html
I did indeed. So never mind about that dmesg request, Paweł ;-p
> Paweł, could you try the attached patch please ?
Thanks f
Added more appropriate people to this. Added both i915 and nouveau
people, since apparently that fine piece of hardware has both.
Guys, any ideas?
Paweł, could you perhaps get a photo of the oops and post it
somewhere? I'm assuming the oops happens early during boot and you
never get a usable mac
This is a couple of high code motion patches (all within arch/parisc)
I'd like to apply at -rc1 to avoid conflicts with anything else. One
moves us on to the generated instead of included asm file model and the
other is a pull request from David Howells for UAPI disintegration.
The patches are he
On 10/18/2012 04:17 PM, H. Peter Anvin wrote:
> On 10/18/2012 05:26 AM, Cédric Godin wrote:
>> Hello,
>>
>> After upgrading my kernel from 3.6 to 3.7-rc1 on my laptop, I can't resume
>> anymore.
>> I bisected the problem to
>>
>
> There is
On 10/18/2012 05:26 AM, Cédric Godin wrote:
Hello,
After upgrading my kernel from 3.6 to 3.7-rc1 on my laptop, I can't resume
anymore.
I bisected the problem to
There is a fix for this already queued up. Please try the attached
patch to verify that it fixes your problem.
I have bisected the code and git tells me the first faulty commit is
f3728734ba78310525bf4a361c7787c7c6fa5d40.
Apparently
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f3728734ba78310525bf4a361c7787c7c6fa5d40)
Apparently, my machine has Atom BIOS but still needs legacy
I have tried to use the framebuffer text console with the latest (as
of yesterday) kernel 3.7-rc1.
I have a Thinkpad Edge 13, model 0197, with onboard Radeon HD3200. So
far, so good, except
that instead of actually blanking the screen and powering it down, the
screen goes blank momentarily
and
>From af0876644f04eca9d59c96320447abb0af526079 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 16 Oct 2012 22:30:38 +0900
Subject: [PATCH 3.7-rc1] Fix kconfig failure on old environments.
Commit 95ac9b3b "menuconfig: Assign jump keys per-page instead of globally"
used mac
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
On 10/14/2012 06:37 PM, Randy Dunlap wrote:
> On 10/14/2012 06:15 PM, Randy Dunlap wrote:
>
>> On 10/14/2012 03:27 PM, Linus Torvalds wrote:
>>
>>> The two weeks are up, and I was merging during my trip, so no reason
>>> for merge window extensions.
>
The VirtualBox kernel modules need to be modified to account for the removal of
VM_RESERVED in version 3.7-rc1. When I used the normal test of
LINUX_VERSION_CODE against KERNEL_VERSION(3, 7, 0), the fix did not work. To
test why, I added the following code snippet to a module:
#if
Hi Randy,
Randy Dunlap wrote:
> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>
> In file included from include/linux/irq.h:22:0,
> from include/asm-generic/hardirq.h:12,
> from arch/um/include/generated/asm/hardirq.h:1,
>
Randy Dunlap wrote:
> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>
> In file included from include/linux/irq.h:22:0,
> from include/asm-generic/hardirq.h:12,
> from arch/um/include/generated/asm/hardirq.h:1,
> from include
On Mon, Oct 15, 2012 at 5:18 PM, Alex Shi wrote:
> Sorry, something in my side. the bisect result is unreliable. I will redo.
Seems the patch-3.7-rc1.bz2 at ftp://www.kernel.org/pub/linux/kernel/
is missed some patches.
but Linus' tree works fine.
>
> On Mon, Oct 15, 2012 at 4:
Sorry, something in my side. the bisect result is unreliable. I will redo.
On Mon, Oct 15, 2012 at 4:30 PM, richard -rw- weinberger
wrote:
> On Mon, Oct 15, 2012 at 6:16 AM, Alex Shi wrote:
>>>
>>> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>>>
>>> In file included from in
On Mon, Oct 15, 2012 at 6:16 AM, Alex Shi wrote:
>>
>> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>>
>> In file included from include/linux/irq.h:22:0,
>> from include/asm-generic/hardirq.h:12,
>> from arch/um/include/generated/asm/hardirq.h
>
> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>
> In file included from include/linux/irq.h:22:0,
> from include/asm-generic/hardirq.h:12,
> from arch/um/include/generated/asm/hardirq.h:1,
> from include/linux/hardirq.h:7,
>
On 10/14/2012 06:15 PM, Randy Dunlap wrote:
> On 10/14/2012 03:27 PM, Linus Torvalds wrote:
>
>> The two weeks are up, and I was merging during my trip, so no reason
>> for merge window extensions.
>>
>> The 3.7-rc1 kernel is out there. There's a few big thi
On 10/14/2012 03:27 PM, Linus Torvalds wrote:
> The two weeks are up, and I was merging during my trip, so no reason
> for merge window extensions.
>
> The 3.7-rc1 kernel is out there. There's a few big things worth noting here:
>
> - the "uapi" include fi
The two weeks are up, and I was merging during my trip, so no reason
for merge window extensions.
The 3.7-rc1 kernel is out there. There's a few big things worth noting here:
- the "uapi" include file cleanups. The idea is that the stuff
exported to user space should now be foun
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-merge-for-3.7-rc1-part2
to receive two more changes for 3.7. There are no conflicts. Thanks.
The following changes since commit 12250d843e8489ee00b5b7726da855e51694e792:
Merge branch
fetch changes up to f7f4b2322bf7b8c5929b7eb5a667091f32592580:
ALSA: hda - do not detect jack on internal speakers for Realtek (2012-10-10
17:13:22 +0200)
Sound updates #2 for 3.7-rc1
This update contains a few cleanup works
Hi Linus,
The following changes since commit 2474542f64432398f503373f53bdf620491bcfa8:
Merge tag 'for-3.7-rc1' of git://gitorious.org/linux-pwm/linux-pwm
(2012-10-10 20:15:24 +0900)
are available in the git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-fo
Linus,
please issue the following pull request.
UML receives this time only cleanups.
The most outstanding change is the 'include "foo.h"' do 'include
'
conversion done by Al Viro.
It touches many files, that's why the diffstat is rather big.
Thanks,
//richard
The following changes sinc
Em Tue, 9 Oct 2012 14:43:46 -0300
Ezequiel Garcia escreveu:
> On Fri, Oct 5, 2012 at 10:42 AM, Mauro Carvalho Chehab
...
> > Ezequiel García (13):
> > [media] em28xx: Remove useless runtime->private_data usage
> > [media] media: Add stk1160 new driver (easycap replacement)
> > [
On Fri, Oct 5, 2012 at 10:42 AM, Mauro Carvalho Chehab
wrote:
> Hi Linus,
>
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> v4l_for_linus
>
> For the first part of the media updates for Kernel 3.7.
>
> This series contain:
>
> - A major tree renam
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin.git for-linus
for you to fetch changes up to 6594b982f6d5f957c8d72de7658b
On Mon, 2012-10-08 at 23:36 -0400, Chris Ball wrote:
> Hi Linus,
>
> On Mon, Oct 08 2012, Chris Ball wrote:
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
> > tags/mmc-merge-for-3.7-rc1
> >
> > to receive th
Hi Linus,
On Mon, Oct 08 2012, Chris Ball wrote:
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
> tags/mmc-merge-for-3.7-rc1
>
> to receive the MMC merge for 3.7. There are currently two conflicts
> due to header renames for the ARM sin
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-merge-for-3.7-rc1
to receive the MMC merge for 3.7. There are currently two conflicts
due to header renames for the ARM single zImage work; they should be
resolved by taking the changes already in
Sound updates for 3.7-rc1
This contains pretty many small commits covering fairly large range of
files in sound/ directory. Partly because of additional API support
and partly because of constantly developed ASoC and ARM stuff.
Some highlights:
- Introduced the helper function and documentatio
55393ba1bdedc5ded79b34b4cc08898a7776cddb:
UBI: fix trivial typo 'it' => 'is' (2012-09-26 13:22:50 +0300)
are available in the git repository at:
git://git.infradead.org/linux-ubi.git tags/upstream-3.7-rc1-fastmap
for you to fetch changes up to 76ac66e469f084d41742ba08923de76fbdc7dce3:
UBI: W
Hi Linus,
This is the follow-up pull, 3 pieces
a) exynos next stuff, was delayed but looks okay to me, one patch in v4l
bits but it was acked by v4l person.
b) UAPI disintegration bits
c) intel fixes - DP fixes, hang fixes, other misc fixes.
Dave.
The following changes since commit 0b8e74c6f4
Hi Linus,
please pull the following changes.
Thanks,
Michal
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linus Torvalds (1):
Linux 3.6
are available in the git repository at:
git://git.monstr.eu/linux-2.6-microblaze.git next
John Linn (1):
mi
Hello Linus,
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus
Shortlog pretty much says it all. Interesting bits are UDF support for
direct IO and ext3 fix for a long standing oops in data=journal mode.
Top of the tree is 09e05d4. The full
* Tony Lindgren [121003 09:00]:
> * Peter Ujfalusi [121003 07:52]:
> > On 10/03/2012 05:31 PM, Tim Gardner wrote:
> > > Cc: Peter Ujfalusi
> > > Cc: Jarkko Nikula
> > > Cc: Liam Girdwood
> > > Cc: Mark Brown
> > > Cc: Jaroslav Kysela
> > > Cc: Takashi Iwai
> > > Cc: linux-o...@vger.kernel.o
* Peter Ujfalusi [121003 07:52]:
> On 10/03/2012 05:31 PM, Tim Gardner wrote:
> > Cc: Peter Ujfalusi
> > Cc: Jarkko Nikula
> > Cc: Liam Girdwood
> > Cc: Mark Brown
> > Cc: Jaroslav Kysela
> > Cc: Takashi Iwai
> > Cc: linux-o...@vger.kernel.org
> > Cc: alsa-de...@alsa-project.org
> > Signed-o
On 10/03/2012 05:31 PM, Tim Gardner wrote:
> Cc: Peter Ujfalusi
> Cc: Jarkko Nikula
> Cc: Liam Girdwood
> Cc: Mark Brown
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: linux-o...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Signed-off-by: Tim Gardner
> ---
> sound/soc/omap/zoom2.c |
Cc: Peter Ujfalusi
Cc: Jarkko Nikula
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: linux-o...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Tim Gardner
---
sound/soc/omap/zoom2.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
1 - 100 of 116 matches
Mail list logo
