ROC=y
CONFIG_PM_RUNTIME=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_FHANDLE=y
CONFIG_EFI_STUB=y
CONFIG_EFIVAR_FS=m
CONFIG_HYPERVISOR_GUEST=y
CONFIG_DRM_CIRRUS_QEMU=y
CONFIG_CFG80211=m
CONFIG_MAC80211=m
CONFIG_IWLWIFI=m
CONFIG_CFG80211_DEFAULT_PS=n
Signed-off-by: F
oves anything that
is in the default defconfig (e.g. x86_64_defconfig)
I've been doing this by hand, but today I gave it a shot to automate this. The
result is a bit crude, but it works.
Thoughts?
Felipe Contreras (2):
kconfig: add KBUILD_USERCONFIG option
kconfig: add KCONFIG_BASECONF
This option parses a defconfig file, and sets all the values as default
ones. The result is a much simplified defconfig.
This defconfig can be used as a KBUILD_USERCONFIG, which added to the
default defconfig generates exactly the same config file.
Signed-off-by: Felipe Contreras
---
scripts
Michal Hocko wrote:
> On Fri 06-06-14 18:11:14, Felipe Contreras wrote:
> > On Fri, Jun 6, 2014 at 5:33 AM, Felipe Contreras
> > wrote:
> > > On Fri, Jun 6, 2014 at 4:16 AM, Michal Hocko wrote:
> > >
> > >> Mel has a nice systemtap script (attached) t
gt; + if (nr_immediate)
> congestion_wait(BLK_RW_ASYNC, HZ/10);
> }
That actually seems to work correctly on v3.15-rc8.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
On Fri, Jun 6, 2014 at 5:33 AM, Felipe Contreras
wrote:
> On Fri, Jun 6, 2014 at 4:16 AM, Michal Hocko wrote:
>
>> Mel has a nice systemtap script (attached) to watch for stalls. Maybe
>> you can give it a try?
>
> Is there any special configurations I should enable?
&g
On Fri, Jun 6, 2014 at 6:03 AM, Michal Hocko wrote:
> On Fri 06-06-14 05:33:28, Felipe Contreras wrote:
>> On Fri, Jun 6, 2014 at 4:16 AM, Michal Hocko wrote:
>>
>> > Mel has a nice systemtap script (attached) to watch for stalls. Maybe
>> > you can give it
reading and writing to the
SSD (although the stall is less severe).
Here's the test:
http://pastie.org/9264124
Just pass a big file as the first argument.
I don't have much memory in this machine, so I guess running out of
memory is the trigger.
--
Felipe Contreras
--
To unsubscribe fro
ch-dstate-new.pl line 320.
--
Felipe Contreras
--
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/
On Fri, Jun 6, 2014 at 4:58 AM, wrote:
> Alternatively can we try wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10) ?
I see the same problem with that code.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Thu, Jun 5, 2014 at 8:37 AM, Michal Hocko wrote:
> On Thu 05-06-14 06:33:40, Felipe Contreras wrote:
>> For a while I've noticed that my machine bogs down in certain
>> situations, usually while doing heavy I/O operations, it is not just the
>> I/O operations, but
_immediate)
congestion_wait(BLK_RW_ASYNC, HZ/10);
After that I don't notice the slow down any more.
Anybody has any ideas how to fix the issue properly?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> * The remote-helper interface to fast-import/fast-export via the
> >>transport-helper has been tightened to avoid leaving the import
> >>marks file from a f
on of itself.
Really? Where are the patches for that?
I think it's fair to say the way the remote-helpers and transport-helper
has been handled for v2.0 has been a total disaster.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
, but since it's 230 lines of
*readable* code, that shouldn't be a problem. I also wrote a blog post
explaining the process that lad me to that code[2].
Cheers.
[1] https://github.com/felipec/finit
[2] http://felipec.wordpress.com/2013/11/04/init/
--
Felipe Contreras
--
To unsubscribe fro
#x27;s patch for that. I think it's justified to put a condom on
> systemd's debug mode given how badly the assertion bug cascaded into
> affecting non-systemd work.
Unfortunately it seems your +1 (and everybody else's in that thread)
didn't matter as the patch was not a
akage.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=76935
--
Felipe Contreras
--
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/
[1] http://article.gmane.org/gmane.comp.version-control.git/246558
--
Felipe Contreras
--
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 re
On Wed, Nov 27, 2013 at 9:47 AM, Jason Baron wrote:
> On 11/27/2013 01:17 AM, Felipe Contreras wrote:
>> Otherwise we might not reboot when the user needs it the most (early
>> on).
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> kernel/panic.c | 7 ++-
Exactly the same as v3, but with an unlrelated patch on top as well.
Felipe Contreras (2):
panic: setup panic_timeout early
panic: setup panic_on_oops early
kernel/panic.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--
1.8.4.2+fc1
--
To unsubscribe from this list
For consistency.
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 3456652..2256838 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -468,7 +468,11 @@ EXPORT_SYMBOL
Otherwise we might not reboot when the user needs it the most (early
on).
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index b6c482c..3456652 100644
--- a/kernel/panic.c
+++ b/kernel
to early_param(). Is that sufficient for the
>> (undescribed!) failure which you are presumably observing?
>
> Also note that that patch is still incomplete: if panic_timeout is
> switched to early_param() then closely related functionality such as
> pause_on_oops should be mo
;t take the patch itself
even though it's obviously good?
> That fix patch had only one remaining bug/problem, last I checked: if
> panic_timeout is turned into an early_param() then pause_on_oops
> should obviously also be turned into an early param.
That is not a "problem&qu
On Sat, Nov 16, 2013 at 2:21 PM, Levente Kurusa wrote:
> 2013-11-16 18:32 keltezéssel, Felipe Contreras írta:
>> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
>> +EXPORT_SYMBOL(memparse);
>>
>> WARNING: EXPORT_SYMBOL(foo); should imme
On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote:
> * Felipe Contreras wrote:
> Anyway, the fact that you are argumentative even with Linus gives me
> little hope that you will improve your communication patterns with
> _me_, so I'm personally done arguing with you
The temporary variable is of the same type as the cast, so it's
redundant.
Signed-off-by: Felipe Contreras
---
lib/kstrtox.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/kstrtox.c b/lib/kstrtox.c
index ec8da78..649b74b 100644
--- a/lib/kstrtox.c
se, no spaces at the start of a line
+ $
WARNING: space prohibited between function name and open parenthesis '('
+ res = get_option ((char **)&str, ints + i);
Signed-off-by: Felipe Contreras
---
lib/cmdline.c | 9 -
1 file changed, 4 insertions(+), 5 deletion
+EXPORT_SYMBOL(get_options);
Signed-off-by: Felipe Contreras
---
lib/cmdline.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index 5466333..d4932f7 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -67,6 +67,7 @@ int get_option(char **str, int *pint
We are repeating the functionality of kstrtol in param_set_long, and the
same for kstrtoint. We can get rid of the extra code by using the right
functions.
Signed-off-by: Felipe Contreras
---
kernel/params.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff
We can't reach the cleanup code unless the flag KSTRTOX_OVERFLOW is not
set, so there's not no point in clearing a bit that we know is not set.
Signed-off-by: Felipe Contreras
---
lib/kstrtox.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/kstrtox.c b/lib/kstrtox.c
ind
Hi,
These became apparent in the review process of a new command line parameter.
Felipe Contreras (5):
kstrtox: remove redundant cleanup
cmdline: fix style issues
cmdline: declare exported symbols immediately
kstrtox: remove redundant casts
params: improve standard definitions
kernel
On Fri, Nov 15, 2013 at 2:15 PM, Linus Torvalds
wrote:
> On Fri, Nov 15, 2013 at 12:10 PM, Felipe Contreras
> wrote:
>>
>> I haven't seen a single complaint about this commit message, so I
>> don't see what is your point.
>
> My point is that I have sixtee
achieve that, and you
might as well simply apply the patch I sent, even though *I* sent it,
because it's technically correct, and the need is explained. Why
wouldn't you?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Otherwise we might not reboot when the user needs it the most (early
on).
Signed-off-by: Felipe Contreras
---
Since v2:
There's no need for a temporary variable because kstrtoint() is already taking
care of that (if there's an error panic_timeout is not updated).
diff --git a/kernel
maybe I made the wrong
assumptions, but at least I didn't throw insults, nor called anybody
names like "childish".
Anyway, I will update the patch to sue kstrtoint(), and I would gladly
fix the existing code for issues 1) 2) and 3) *if* you or anybody
agrees they should be using kstrto
Hi,
Sending again since the previous one was rejected by the server.
On Thu, Nov 14, 2013 at 3:25 PM, Felipe Contreras
wrote:
> Levente Kurusa wrote:
>> 2013-11-14 12:16 keltezéssel, Felipe Contreras írta:
>> > On Tue, Nov 12, 2013 at 6:03 PM, Ingo Molnar wrote:
>> >
On Tue, Nov 12, 2013 at 6:03 PM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> Otherwise we might not reboot when the user needs it the most (early
>> on).
>>
>> Signed-off-by: Felipe Contreras
>> ---
>>
> [...]
>>
>> d
o '' | make oldconfig
But it's very hacky and I see tons of errors reported, but it does
what I expect.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
f the patch is technically correct, conforms to standard practices,
and solves a problem; it gets applied. Isn't that how it works in
Linux?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
Otherwise we might not reboot when the user needs it the most (early
on).
Signed-off-by: Felipe Contreras
---
This time using kstrtol() instead of get_option().
Interdiff:
diff --git a/kernel/panic.c b/kernel/panic.c
index 46e37ff..d865263 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
On Mon, Nov 11, 2013 at 8:22 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> On Mon, Nov 11, 2013 at 7:44 AM, Ingo Molnar wrote:
>> >
>> > * Felipe Contreras wrote:
>> >
>> >> Otherwise we might not reboot when the user needs i
On Mon, Nov 11, 2013 at 7:54 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> On Mon, Nov 11, 2013 at 7:19 AM, Ingo Molnar wrote:
>> >
>> > * Felipe Contreras wrote:
>> >
>> >> Signed-off-by: Felipe Contreras
>> >
>
On Mon, Nov 11, 2013 at 7:44 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> Otherwise we might not reboot when the user needs it the most (early
>> on).
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> kernel/panic.c | 14 +
Otherwise we might not reboot when the user needs it the most (early
on).
Signed-off-by: Felipe Contreras
---
This is exactly the same as in the previous try, but now alone since it was
mudded by largely irrelevant patches in the series.
kernel/panic.c | 14 +-
1 file changed, 13
On Mon, Nov 11, 2013 at 7:28 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> On Mon, Nov 11, 2013 at 6:49 AM, Ingo Molnar wrote:
>> >
>> > * Felipe Contreras wrote:
>> >
>> >> On Mon, Nov 11, 2013 at 5:32 AM, Ingo Mo
On Mon, Nov 11, 2013 at 7:19 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> Signed-off-by: Felipe Contreras
>
> The changelog is missing and the title is not self-explanatory.
Either the local IRQs should be enabled for both the restart and halt
blinks, or it
On Mon, Nov 11, 2013 at 6:49 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> On Mon, Nov 11, 2013 at 5:32 AM, Ingo Molnar wrote:
>> >
>> > * Felipe Contreras wrote:
>> >
>> >> We want to calculate the blinks per second, and in
On Mon, Nov 11, 2013 at 5:32 AM, Ingo Molnar wrote:
>
> * Felipe Contreras wrote:
>
>> We want to calculate the blinks per second, and instead of making it 5
>> (1000 / (3600 / 18)), let's make it 4, so the user can see two blinks
>> per second.
>
> Pleas
itorious.org/linux-n900/linux-n900
How did you test these patches? I get a panic loop immediately after I
bring the interface loop in monitor mode (v3.12).
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
Hi,
While debugging a hang after panic in my laptop (I cannot hard-reboot, or
unplug the battery), I noticed the panic code has some areas of improvment.
Only the first patch is really needed, the rest seem like good to have.
Felipe Contreras (3):
panic: setup panic_timeout early
panic
Otherwise we might not reboot when the user needs it the most (early
on).
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index b6c482c..46e37ff 100644
--- a/kernel/panic.c
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index 5a0bdaa..e32919f 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -133,6 +133,8 @@ void panic(const char *fmt
We want to calculate the blinks per second, and instead of making it 5
(1000 / (3600 / 18)), let's make it 4, so the user can see two blinks
per second.
Signed-off-by: Felipe Contreras
---
kernel/panic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/pani
On Tue, Nov 5, 2013 at 8:19 PM, Greg Kroah-Hartman
wrote:
> On Tue, Nov 05, 2013 at 01:54:51PM -0600, Felipe Contreras wrote:
>> On Tue, Nov 5, 2013 at 9:16 AM, Greg Kroah-Hartman
>> wrote:
>> > On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote:
>>
On Tue, Nov 5, 2013 at 9:16 AM, Greg Kroah-Hartman
wrote:
> On Tue, Nov 05, 2013 at 08:29:40AM -0600, Felipe Contreras wrote:
>> On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman
>> wrote:
>> > On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote:
>&
be saved after it has been manually changed because
it won't be reported properly until it goes back to 'auto' mode.
[1]
http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
Signed-off-by: Felipe Contreras
---
Changes since v1:
* Added
On Tue, Nov 5, 2013 at 6:52 AM, Greg Kroah-Hartman
wrote:
> On Tue, Nov 05, 2013 at 02:59:47AM -0600, Felipe Contreras wrote:
>> Simple driver to enable control of the fan in ASUS laptops. So far this
>> has only been tested in ASUS Zenbook Prime UX31A, but according to some
>
be saved after it has been manually changed because
it won't be reported properly until it goes back to 'auto' mode.
[1]
http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
Signed-off-by: Felipe Contreras
---
Two incarnations of this
On Fri, Oct 18, 2013 at 5:43 AM, Stefan Hellermann
wrote:
> 2013/10/3 Felipe Contreras
>>
>> On Thu, Oct 3, 2013 at 12:13 PM, Felipe Contreras
>> wrote:
>> > More people have reported they need this for their machines to work
>> > correctly.
>> >
On Mon, Oct 14, 2013 at 6:34 PM, Matthew Garrett wrote:
> On Mon, Oct 14, 2013 at 06:27:33PM -0500, Felipe Contreras wrote:
>> On Mon, Oct 14, 2013 at 6:22 PM, Matthew Garrett wrote:
>> > The easiest is to just do it from userspace. I think Intel have some
>> > code fo
On Mon, Oct 14, 2013 at 6:22 PM, Matthew Garrett wrote:
> On Mon, Oct 14, 2013 at 06:18:36PM -0500, Felipe Contreras wrote:
>> On Mon, Oct 14, 2013 at 10:52 AM, Matthew Garrett
>> wrote:
>> > It wouldn't be appropriate to alter the firmware behaviour by default,
&
On Mon, Oct 14, 2013 at 10:52 AM, Matthew Garrett wrote:
> On Sun, Oct 13, 2013 at 09:31:25PM -0500, Felipe Contreras wrote:
>> On Sun, Oct 13, 2013 at 10:17 AM, Matthew Garrett
>> wrote:
>> > The spec doesn't seem to constrain it to physical addresses (it just
&g
On Mon, Oct 14, 2013 at 9:16 AM, Rafael J. Wysocki wrote:
> On Monday, October 14, 2013 08:14:28 AM Felipe Contreras wrote:
>> On Mon, Oct 14, 2013 at 6:58 AM, Rafael J. Wysocki wrote:
>> > On Sunday, October 13, 2013 10:30:50 PM Felipe Contreras wrote:
>> >> O
On Mon, Oct 14, 2013 at 6:58 AM, Rafael J. Wysocki wrote:
> On Sunday, October 13, 2013 10:30:50 PM Felipe Contreras wrote:
>> On Thu, Oct 3, 2013 at 12:13 PM, Felipe Contreras
>> wrote:
>> > More people have reported they need this for their machines to work
>>
On Thu, Oct 3, 2013 at 12:13 PM, Felipe Contreras
wrote:
> More people have reported they need this for their machines to work
> correctly.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=60682
I see this was merged to the linux-next branch. Is there any reason
why it's not p
On Sun, Oct 13, 2013 at 10:17 AM, Matthew Garrett wrote:
> On Sun, Oct 13, 2013 at 04:29:34AM -0500, Felipe Contreras wrote:
>
>> I don't see anything in acpi_ex_system_memory_space_handler() that
>> takes into consideration virtual addresses.
>
> The spec doesn'
hardware - are we artificially limiting
> SystemMemory opregions to physical addresses?
I don't see anything in acpi_ex_system_memory_space_handler() that
takes into consideration virtual addresses.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linu
On Thu, Oct 10, 2013 at 10:59 AM, Corentin Chary
wrote:
>
>
>
> On Tue, Oct 8, 2013 at 1:48 PM, Felipe Contreras
> wrote:
>>
>> Simple driver to enable control of the fan in ASUS laptops. So far this
>> has only been tested in ASUS Zenbook Prime UX31A, but acco
On Tue, Oct 8, 2013 at 7:48 AM, Felipe Contreras
wrote:
> Simple driver to enable control of the fan in ASUS laptops. So far this
> has only been tested in ASUS Zenbook Prime UX31A, but according to some
> online reference [1], it should work in other models as well.
>
> The im
be saved after it has been manually changed because
it won't be reported properly until it goes back to 'auto' mode.
[1]
http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
Signed-off-by: Felipe Contreras
---
drivers/platform/x86/a
Signed-off-by: Felipe Contreras
---
drivers/platform/x86/asus-laptop.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 0e9c169..0210cf4 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b
Signed-off-by: Felipe Contreras
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index 41ade65..ba3da88 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -168,7 +168,7 @@ static int acpi_fan_add(struct
Hi,
Exactly the same as last time.
Felipe Contreras (2):
acpi: fan: trivial style cleanup
x86: asus-laptop: trivial style cleanups
drivers/acpi/fan.c | 2 +-
drivers/platform/x86/asus-laptop.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
--
1.8.4-fc
--
To
> won't need to worry about ordering-specific semantics getting smashed.
How about we worry about hypothetical issues when they arise? (which
is probably going to be never).
Personally I think this is more than enough:
http://article.gmane.org/gmane.linux.acpi.devel/64243
--
Felipe C
On Sun, Oct 6, 2013 at 8:27 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 08:01:34PM -0500, Felipe Contreras wrote:
>> On Sun, Oct 6, 2013 at 7:53 PM, Matthew Garrett wrote:
>> > No, it demonstrably doesn't. The comments that do exist refer to only a
>> >
ernel/1572459
Signed-off-by: Felipe Contreras
---
drivers/acpi/blacklist.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 9515f18..42cccbe 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -273,6 +273,11 @@ s
On Sun, Oct 6, 2013 at 7:53 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 07:50:18PM -0500, Felipe Contreras wrote:
>> On Sun, Oct 6, 2013 at 7:32 PM, Matthew Garrett wrote:
>> > I don't get the final
>> > say in whether or not this patch gets merged, but t
On Sun, Oct 6, 2013 at 7:32 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 07:27:48PM -0500, Felipe Contreras wrote:
>
>> If _you_ want to add comments for each entry in the list you can do so
>> after this patch is applied.
>
> If you want to participate in a c
On Sun, Oct 6, 2013 at 6:57 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 06:36:57PM -0500, Felipe Contreras wrote:
>> On Sun, Oct 6, 2013 at 6:31 PM, Matthew Garrett wrote:
>> > On Sun, Oct 06, 2013 at 06:27:28PM -0500, Felipe Contreras wrote:
>> &g
On Sun, Oct 6, 2013 at 6:31 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 06:27:28PM -0500, Felipe Contreras wrote:
>> From acpi_osi_dmi_table:
>>
>> /*
>> * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
>> * Linux ignores it, except
On Sun, Oct 6, 2013 at 3:59 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 03:51:05PM -0500, Felipe Contreras wrote:
>> On Sun, Oct 6, 2013 at 3:45 PM, Matthew Garrett wrote:
>> > On Sun, Oct 06, 2013 at 03:40:42PM -0500, Felipe Contreras wrote:
>> >
>> >
On Sun, Oct 6, 2013 at 3:45 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 03:40:42PM -0500, Felipe Contreras wrote:
>
>> In case you didn't hear, the plan was to add an entry if a user
>> reports the backlight not working correctly, and acpi_osi="!Window
On Sun, Oct 6, 2013 at 3:33 PM, Matthew Garrett wrote:
> On Sun, Oct 06, 2013 at 03:29:10PM -0500, Felipe Contreras wrote:
>> On Fri, Oct 4, 2013 at 11:12 AM, Matthew Garrett wrote:
>> > On Thu, Oct 03, 2013 at 12:13:03PM -0500, Felipe Contreras wrote:
>> >> More
On Fri, Oct 4, 2013 at 11:12 AM, Matthew Garrett wrote:
> On Thu, Oct 03, 2013 at 12:13:03PM -0500, Felipe Contreras wrote:
>> More people have reported they need this for their machines to work
>> correctly.
>
> Can you add a comment to each indicating why they're bein
On Thu, Oct 3, 2013 at 12:13 PM, Felipe Contreras
wrote:
> More people have reported they need this for their machines to work
> correctly.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=60682
Reported-by: Stefan Hellermann
Reported-by: Benedikt Sauer
Reported-by: Erno Kuusela
More people have reported they need this for their machines to work
correctly.
https://bugzilla.kernel.org/show_bug.cgi?id=60682
Signed-off-by: Felipe Contreras
---
drivers/acpi/blacklist.c | 48
1 file changed, 48 insertions(+)
diff --git a
Signed-off-by: Felipe Contreras
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index 5b02a0a..0898649 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -168,7 +168,7 @@ static int acpi_fan_add(struct
Signed-off-by: Felipe Contreras
---
drivers/platform/x86/asus-laptop.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 8e268da..81a5f26 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b
t;!Windows 2012").
Once the Intel backlight driver works correctly for all machines, this
blacklist can be removed and that driver can be used instead.
https://bugzilla.kernel.org/show_bug.cgi?id=60682
Signed-off-by: Felipe Contreras
---
drivers/acpi/b
On Thu, Aug 22, 2013 at 4:38 PM, Rafael J. Wysocki wrote:
> On Thursday, August 22, 2013 01:31:11 PM Felipe Contreras wrote:
>> _BCM_use_index and _BCL_use_index are never used and probably never will.
>>
>> Signed-off-by: Felipe Contreras
>
> I have this patch in the
_BCM_use_index and _BCL_use_index are never used and probably never will.
Signed-off-by: Felipe Contreras
---
drivers/acpi/video.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index e1284b8..e6be27e 100644
--- a/drivers/acpi
On Thu, Aug 15, 2013 at 2:22 AM, Zhang Rui wrote:
> On 二, 2013-08-06 at 17:48 -0500, Felipe Contreras wrote:
>> Simple driver to enable control of the fan in ASUS laptops. So far this
>> has only been tested in ASUS Zenbook Prime UX31A, but according to some
>> online ref
http://forum.notebookreview.com/asus/705656-fan-control-asus-prime-ux31-ux31a-ux32a-ux32vd.html
[2]
http://www.mail-archive.com/acpi4asus-user@lists.sourceforge.net/msg00065.html
Signed-off-by: Felipe Contreras
---
I've never implemented a driver like this, so I've no idea if this is the right
way to d
On Mon, Aug 5, 2013 at 12:43 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
> wrote:
>
>> That said, Felipe, can you double-check that it's not timing-related
>> in some subtle way, and test multiple times with just that commit
>>
27;t seem to be a race.
But I'll double-check.
--
Felipe Contreras
--
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/
On Mon, Aug 5, 2013 at 12:11 PM, Oleg Nesterov wrote:
> On 08/05, Felipe Contreras wrote:
>>
>> On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov wrote:
>> >
>> > Hmm. It should not crash under strace... please see below.
>> >
>> >> 953 ptrac
On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov wrote:
> On 08/05, Felipe Contreras wrote:
>>
>> On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov wrote:
>> >
>> > Could you please run wine under strace
>> >
>> > strace -f -e ptrace -o LOG
> The only common denominator is what Windows expects (and that unfortunately
> depends on the version of Windows too), because that's the functionality
> which is likely to have been tested. Anything else is likely to be untested
> and therefore most probably buggy.
Maybe, or maybe
On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov wrote:
> On 08/04, Felipe Contreras wrote:
>>
>> I found a regression while running all v3.11-rcX kernels; Starcract II
>> through wine crashes.
>
> Thanks... just to clarify, Starcract crashes, wine or kernel?
It's St
1 - 100 of 180 matches
Mail list logo
