Re: [PATCH AUTOSEL for 4.15 142/189] firmware: dmi_scan: Fix handling of empty DMI strings

On Mon, Apr 9, 2018 at 8:48 AM, Jean Delvare wrote: > As a conclusion, it's doable, but the benefit is very small and limited > to a few broken systems, and it has the downside of not discouraging > low-quality tables, so my position is that it's not worth it and not >

Re: [PATCH AUTOSEL for 4.15 142/189] firmware: dmi_scan: Fix handling of empty DMI strings

On Mon, Apr 9, 2018 at 8:48 AM, Jean Delvare wrote: > As a conclusion, it's doable, but the benefit is very small and limited > to a few broken systems, and it has the downside of not discouraging > low-quality tables, so my position is that it's not worth it and not > desirable. Thanks for the

xhci dmesg flood on short packet

I see a continuous flood of below messages on plugging in/using my USB token. (The comp code wasn't in the original message - I added it.) From what I can tell the device continues to work as expected. Should the warning be disabled for COMP_SHORT_TX like it is for COMP_STOP and

xhci dmesg flood on short packet

I see a continuous flood of below messages on plugging in/using my USB token. (The comp code wasn't in the original message - I added it.) From what I can tell the device continues to work as expected. Should the warning be disabled for COMP_SHORT_TX like it is for COMP_STOP and

Re: BAR 14: can't assign mem (size 0x200000)

On Thu, 10 Apr 2014, Bjorn Helgaas wrote: > On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar wrote: > >> On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote: > > > >>> Parag, can you add a WARN_ON_ONCE() to that message, so that we see > >>>

Re: BAR 14: can't assign mem (size 0x200000)

On Thu, 10 Apr 2014, Bjorn Helgaas wrote: On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar parag.l...@gmail.com wrote: On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote: Parag, can you add a WARN_ON_ONCE() to that message, so that we see what the call chain

Re: BAR 14: can't assign mem (size 0x200000)

On Thu, 10 Apr 2014, Bjorn Helgaas wrote: > On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar wrote: > >> On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote: > > > >>> Parag, can you add a WARN_ON_ONCE() to that message, so that we see > >>>

Re: BAR 14: can't assign mem (size 0x200000)

On Thu, 10 Apr 2014, Bjorn Helgaas wrote: On Sat, Mar 29, 2014 at 6:14 PM, Parag Warudkar parag.l...@gmail.com wrote: On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote: Parag, can you add a WARN_ON_ONCE() to that message, so that we see what the call chain

Re: BAR 14: can't assign mem (size 0x200000)

On Sat, Mar 29, 2014 at 1:19 PM, Bjorn Helgaas wrote: > [+cc Rafael, linux-pci, linux-acpi] > > On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote: >> Parag, can you add a WARN_ON_ONCE() to that message, so that we see >> what the call chain is for it. > > I think we likely get a Bus

Re: BAR 14: can't assign mem (size 0x200000)

On Sat, Mar 29, 2014 at 3:11 AM, Yinghai Lu wrote: > > For the boot path, kernel is right. > BIOS does not assign resource for > 00:1c.0, (io, mmio, mmio pref), 00:1c.3(io, mmio, mmio pref), 00:1c.4 (io). > > but 00:1c.0 00:1c.4 support hotplug either in acpiphp or pcie slot cap. > > [

Re: BAR 14: can't assign mem (size 0x200000)

On Sat, Mar 29, 2014 at 3:11 AM, Yinghai Lu ying...@kernel.org wrote: For the boot path, kernel is right. BIOS does not assign resource for 00:1c.0, (io, mmio, mmio pref), 00:1c.3(io, mmio, mmio pref), 00:1c.4 (io). but 00:1c.0 00:1c.4 support hotplug either in acpiphp or pcie slot cap. [

Re: BAR 14: can't assign mem (size 0x200000)

On Sat, Mar 29, 2014 at 1:19 PM, Bjorn Helgaas bhelg...@google.com wrote: [+cc Rafael, linux-pci, linux-acpi] On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote: Parag, can you add a WARN_ON_ONCE() to that message, so that we see what the call chain is for it. I think we likely

BAR 14: can't assign mem (size 0x200000)

No issues with fresh boot, however after resume from suspend I see these messages - [11548.934625] pci_bus :03: Allocating resources [11548.934645] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [11548.934648] pci :02:00.0: bridge window [mem

BAR 14: can't assign mem (size 0x200000)

No issues with fresh boot, however after resume from suspend I see these messages - [11548.934625] pci_bus :03: Allocating resources [11548.934645] pci :02:00.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000 [11548.934648] pci :02:00.0: bridge window [mem

Re: [PATCH] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)

On Tue, Jul 16, 2013 at 7:32 PM, Andy Lutomirski wrote: > Fair enough. I leave it to the experts to comment on whether there > should be some explicit check of whether this is > EFI_BOOT_SERVICES_DATA. > I am reading the code again and something doesn't sound right. The original code calls

Fwd: [PATCH] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)

On Jul 16, 2013 6:55 PM, "Andy Lutomirski" wrote: > > Ok, so I played around with it a bit and the following patch works > > fine on my system. (I.E. image size is reasonable, cat > > /sys/firmware/acpi/bgrt/image > img.bmp generates a valid, > > non-distorted bitmap, which it did before too,

[PATCH] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)

On Mon, Jul 15, 2013 at 8:00 PM, Parag Warudkar wrote: > On Mon, Jul 15, 2013 at 7:56 PM, Parag Warudkar wrote: >> On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett wrote: >> >>> We do need to handle the case of a valid pointer into memory that e820 >>> call

[PATCH] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)

On Mon, Jul 15, 2013 at 8:00 PM, Parag Warudkar parag.l...@gmail.com wrote: On Mon, Jul 15, 2013 at 7:56 PM, Parag Warudkar parag.l...@gmail.com wrote: On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett j...@joshtriplett.org wrote: We do need to handle the case of a valid pointer into memory

Fwd: [PATCH] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)

On Jul 16, 2013 6:55 PM, Andy Lutomirski l...@amacapital.net wrote: Ok, so I played around with it a bit and the following patch works fine on my system. (I.E. image size is reasonable, cat /sys/firmware/acpi/bgrt/image img.bmp generates a valid, non-distorted bitmap, which it did before

Re: [PATCH] BGRT: Don't ioremap if image address is in System RAM (was: Re: BGRT Pointer in System RAM)

On Tue, Jul 16, 2013 at 7:32 PM, Andy Lutomirski l...@amacapital.net wrote: Fair enough. I leave it to the experts to comment on whether there should be some explicit check of whether this is EFI_BOOT_SERVICES_DATA. I am reading the code again and something doesn't sound right. The original

Re: BGRT Pointer in System RAM

On Mon, Jul 15, 2013 at 7:56 PM, Parag Warudkar wrote: > On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett wrote: > >> We do need to handle the case of a valid pointer into memory that e820 >> calls system RAM, as well as the case of a valid pointer into memory >> reserved

Re: BGRT Pointer in System RAM

On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett wrote: > We do need to handle the case of a valid pointer into memory that e820 > calls system RAM, as well as the case of a valid pointer into memory > reserved for the BIOS or similar, but not the case of an invalid > pointer. Would that be as

Re: BGRT Pointer in System RAM

On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett j...@joshtriplett.org wrote: We do need to handle the case of a valid pointer into memory that e820 calls system RAM, as well as the case of a valid pointer into memory reserved for the BIOS or similar, but not the case of an invalid pointer.

Re: BGRT Pointer in System RAM

On Mon, Jul 15, 2013 at 7:56 PM, Parag Warudkar parag.l...@gmail.com wrote: On Mon, Jul 15, 2013 at 7:04 PM, Josh Triplett j...@joshtriplett.org wrote: We do need to handle the case of a valid pointer into memory that e820 calls system RAM, as well as the case of a valid pointer into memory

BGRT Pointer in System RAM

Saw this warning running latest git (Ubuntu daily mainline.) It looked similar to what Andy saw on MSI hardware - http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for it doesn't seem to be merged, although it won't help in my case - different hardware with valid status instead of

BGRT Pointer in System RAM

Saw this warning running latest git (Ubuntu daily mainline.) It looked similar to what Andy saw on MSI hardware - http://www.spinics.net/lists/linux-acpi/msg43410.html . The patch for it doesn't seem to be merged, although it won't help in my case - different hardware with valid status instead of

Re: [PATCH] radeon: Allow disabling UVD

On Wed, 8 May 2013, Parag Warudkar wrote: > > > On Wed, 8 May 2013, Christian König wrote: > > > If you want to hack a bit on it you could try commenting out the calls to > > "radeon_set_uvd_clocks" in radeon_uvd.c. That should give you the default > >

Re: [PATCH] radeon: Allow disabling UVD

On Wed, 8 May 2013, Parag Warudkar wrote: On Wed, 8 May 2013, Christian König wrote: If you want to hack a bit on it you could try commenting out the calls to radeon_set_uvd_clocks in radeon_uvd.c. That should give you the default clocks of 100Mhz, not enough for usable decoding

Re: [PATCH] radeon: Allow disabling UVD

On Wed, 8 May 2013, Christian König wrote: > Am 07.05.2013 23:13, schrieb Parag Warudkar: > > On Tue, May 7, 2013 at 4:44 AM, Christian König > > wrote: > > Without SUMO_uvd.bin - suspends fine and only wakes up when I want it to. > > Hui? Wait a second, the firm

Re: HID: protect hid_debug_list

Hi Jiri Commit 2353f2bea307390e015493118e425152b8a5a431 HID: protect hid_debug_list causes the below BUG due to mutex_lock being called in atomic context - does this need to be converted to a spin lock? [ 5636.125330] BUG: sleeping function called from invalid context at kernel/mutex.c:95 [

Re: HID: protect hid_debug_list

Hi Jiri Commit 2353f2bea307390e015493118e425152b8a5a431 HID: protect hid_debug_list causes the below BUG due to mutex_lock being called in atomic context - does this need to be converted to a spin lock? [ 5636.125330] BUG: sleeping function called from invalid context at kernel/mutex.c:95 [

Re: [PATCH] radeon: Allow disabling UVD

On Wed, 8 May 2013, Christian König wrote: Am 07.05.2013 23:13, schrieb Parag Warudkar: On Tue, May 7, 2013 at 4:44 AM, Christian König deathsim...@vodafone.de wrote: Without SUMO_uvd.bin - suspends fine and only wakes up when I want it to. Hui? Wait a second, the firmware doesn't

Re: Immediate wakeup after suspend

On Mon, May 6, 2013 at 8:57 PM, Parag Warudkar wrote: > On Mon, May 6, 2013 at 8:45 PM, Rafael J. Wysocki wrote: >>> I have tried disabling EHC1 and EHC2 without any difference. >> >> That may mean one of two things: (1) After you'd tried that they appeared as >&g

Re: [PATCH] radeon: Allow disabling UVD

On Tue, May 7, 2013 at 4:44 AM, Christian König wrote: > > The patch shouldn't be necessary because just removing the firmware should > have pretty much the same effect. Soon distros will ship the UVD firmware by default and then users will need to manually remove it and then do the same with

Re: [PATCH] radeon: Allow disabling UVD

On Tue, May 7, 2013 at 4:44 AM, Christian König deathsim...@vodafone.de wrote: The patch shouldn't be necessary because just removing the firmware should have pretty much the same effect. Soon distros will ship the UVD firmware by default and then users will need to manually remove it and

Re: Immediate wakeup after suspend

On Mon, May 6, 2013 at 8:57 PM, Parag Warudkar parag.l...@gmail.com wrote: On Mon, May 6, 2013 at 8:45 PM, Rafael J. Wysocki r...@sisk.pl wrote: I have tried disabling EHC1 and EHC2 without any difference. That may mean one of two things: (1) After you'd tried that they appeared as disabled

Re: Immediate wakeup after suspend

On Mon, May 6, 2013 at 8:45 PM, Rafael J. Wysocki wrote: >> I have tried disabling EHC1 and EHC2 without any difference. > > That may mean one of two things: (1) After you'd tried that they appeared as > disabled, but the immediate wakeup still happened or (2) you'd tried to > disable them, but

[PATCH] radeon: Allow disabling UVD

Apparently UVD doesn't yet work everywhere - so allow it to be disabled. Shaves off some reboot and suspend/resume time on machines where it doesn't work. Might be useful for problematic chips in the future as well. Patch attached as well as inline below. Signed-off-by: Parag Warudkar diff

Immediate wakeup after suspend

Sometime after 3.9 my iMac has started to resume almost immediately after suspend. Even with 3.9 it was all working as expected. Relevant dmesg output below. Any way to find out the source of the wakeup? Thanks, Parag Linux parag-iMac 3.9.0+ #5 SMP PREEMPT Mon May 6 17:01:19 EDT 2013 x86_64

Immediate wakeup after suspend

Sometime after 3.9 my iMac has started to resume almost immediately after suspend. Even with 3.9 it was all working as expected. Relevant dmesg output below. Any way to find out the source of the wakeup? Thanks, Parag Linux parag-iMac 3.9.0+ #5 SMP PREEMPT Mon May 6 17:01:19 EDT 2013 x86_64

Re: [PATCH] cpufreq/intel_pstate: Set timer timeout correctly

> timeout being set to jiffies + 1 which setup the driver to race with > > it's self if the apic timer interrupt happen at just the right time. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=920289 > > > > Reported-by: Adam Williamson &

Re: [PATCH] cpufreq/intel_pstate: Set timer timeout correctly

in the timeout being set to jiffies + 1 which setup the driver to race with it's self if the apic timer interrupt happen at just the right time. https://bugzilla.redhat.com/show_bug.cgi?id=920289 Reported-by: Adam Williamson awill...@redhat.com Reported-by: Parag Warudkar parag.l

Re: intel_pstate_timer_func divide by zero oops

On Thu, Mar 28, 2013 at 11:35 AM, Dirk Brandewie wrote: >>> pid_param_set() is on the stack which means that something is changing >>> the debugfs parameters or the stack is FUBAR. >>> >> I somehow doubt the stack is messed up as the call traces are always >> identical. >> (pid_param_set() seems

Re: intel_pstate_timer_func divide by zero oops

On Thu, Mar 28, 2013 at 11:35 AM, Dirk Brandewie dirk.brande...@gmail.com wrote: pid_param_set() is on the stack which means that something is changing the debugfs parameters or the stack is FUBAR. I somehow doubt the stack is messed up as the call traces are always identical.

Re: intel_pstate_timer_func divide by zero oops

On Wed, Mar 27, 2013 at 10:51 PM, Dirk Brandewie wrote: > > Is there any way to capture the beginning of this trace? I tried but since the oops scrolls fast followed by a hard freeze, I wasn't able to capture it completely. May be I can try netconsole and see if that helps. > > pid_param_set()

intel_pstate_timer_func divide by zero oops

I get this same oops occassionally - the machine freezes and there doesn't seem to be any record of the oops on disk. I captured it on camera - https://lh3.googleusercontent.com/-K0lNbJrZBMQ/UVOU1vv1vvI/NqI/pY92mWm3caE/s800/20130327_205245.jpg If I am reading this right, it dies on

intel_pstate_timer_func divide by zero oops

I get this same oops occassionally - the machine freezes and there doesn't seem to be any record of the oops on disk. I captured it on camera - https://lh3.googleusercontent.com/-K0lNbJrZBMQ/UVOU1vv1vvI/NqI/pY92mWm3caE/s800/20130327_205245.jpg If I am reading this right, it dies on

Re: intel_pstate_timer_func divide by zero oops

On Wed, Mar 27, 2013 at 10:51 PM, Dirk Brandewie dirk.brande...@gmail.com wrote: Is there any way to capture the beginning of this trace? I tried but since the oops scrolls fast followed by a hard freeze, I wasn't able to capture it completely. May be I can try netconsole and see if that helps.

Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend

ue_work(sc->hw, >hw_check_work); >> > } >> >> That looks ok for me as -stable fix >> >> Reviewed-by: Stanislaw Gruszka > > Parag, can you test the above to ensure it fixes your issue ? Seems to be working ok so far. Reported-and-tested-by: Parag Warudk

Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend

to ensure it fixes your issue ? Seems to be working ok so far. Reported-and-tested-by: Parag Warudkar parag.l...@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

Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend

On Mon, 18 Mar 2013, Luis R. Rodriguez wrote: > > Note that what this will do is call later mod_timer() for > rx_poll_timer, the right thing to do then, which would > be equivalent to your patch is to modify the ath_start_rx_poll() > to instead use the new API mod_timer_pending() added on

Re: [ 00/48] 3.4.37-stable review

On Mon, 18 Mar 2013, Shuah Khan wrote: > I am seeing the following warning after suspend and resume: > > [ 665.841331] Component: resume devices, time: 10628 [snip] > [ 665.841446] Pid: 2686, comm: bash Not tainted 3.4.37-rc1+ #13 > [ 665.841450] Call Trace: > [ 665.841463] []

Re: [ 00/48] 3.4.37-stable review

On Mon, 18 Mar 2013, Shuah Khan wrote: I am seeing the following warning after suspend and resume: [ 665.841331] Component: resume devices, time: 10628 [snip] [ 665.841446] Pid: 2686, comm: bash Not tainted 3.4.37-rc1+ #13 [ 665.841450] Call Trace: [ 665.841463] [8105136f]

Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend

On Mon, 18 Mar 2013, Luis R. Rodriguez wrote: Note that what this will do is call later mod_timer() for rx_poll_timer, the right thing to do then, which would be equivalent to your patch is to modify the ath_start_rx_poll() to instead use the new API mod_timer_pending() added on v2.6.30

Re: [PATCH] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume

On Sat, Mar 16, 2013 at 1:56 PM, Linus Torvalds wrote: > On Sat, Mar 16, 2013 at 9:11 AM, Parag Warudkar wrote: >> >> This seems to trigger a WARN_ON during suspend/resume. > > Ugh, yes. It's practically harmless, but it's ugly and technically > wrong (we're using wrmsr

[PATCH] ath9k : Fix ieee80211 work while going to suspend

09:39:17 Parags-iMac kernel: [ 3993.643068] [] x86_64_start_kernel+0x100/0x10f Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643068] ---[ end trace 5595a7f5dd9a2949 ]--- Signed-off-by: Parag Warudkar diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index

Re: [PATCH] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume

On Fri, Mar 15, 2013 at 9:26 AM, Stephane Eranian wrote: > > This patch fixes a kernel crash when using precise sampling (PEBS) > after a suspend/resume. Turns out the CPU notifier code is not invoked > on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly > by the kernel

Re: [PATCH] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume

On Fri, Mar 15, 2013 at 9:26 AM, Stephane Eranian eran...@google.com wrote: This patch fixes a kernel crash when using precise sampling (PEBS) after a suspend/resume. Turns out the CPU notifier code is not invoked on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly by

[PATCH] ath9k : Fix ieee80211 work while going to suspend

: [ 3993.643068] ---[ end trace 5595a7f5dd9a2949 ]--- Signed-off-by: Parag Warudkar parag.l...@gmail.com diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h index a56b241..b3088a1 100644 --- a/drivers/net/wireless/ath/ath9k/ath9k.h +++ b/drivers/net/wireless

Re: [PATCH] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume

On Sat, Mar 16, 2013 at 1:56 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sat, Mar 16, 2013 at 9:11 AM, Parag Warudkar parag.l...@gmail.com wrote: This seems to trigger a WARN_ON during suspend/resume. Ugh, yes. It's practically harmless, but it's ugly and technically wrong

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Mon, 17 Sep 2012, Henrik Rydberg wrote: > So the question is, does this patch work equally well for you? > > > diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c > index 2827088..8bf9011 100644 > --- a/drivers/hwmon/applesmc.c > +++ b/drivers/hwmon/applesmc.c > @@ -56,7 +56,7

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

ail Since the write fails are confirmed, I've locally dropped the send_byte changes and just kept the wait_read ones that haven't caused me any trouble yet. Signed-off-by: Parag Warudkar diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index 2827088..2ba298a 100644 --- a/drivers/hw

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Mon, 17 Sep 2012, Henrik Rydberg wrote: > The current patch does exactly the same sleeps, the only difference is > that the test is also done before the first sleep. Thus, the increased > delay, if any, comes from the sleep range. My understanding is that the original patch resulted in

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Mon, 17 Sep 2012, Henrik Rydberg wrote: The current patch does exactly the same sleeps, the only difference is that the test is also done before the first sleep. Thus, the increased delay, if any, comes from the sleep range. My understanding is that the original patch resulted in trying a

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

Since the write fails are confirmed, I've locally dropped the send_byte changes and just kept the wait_read ones that haven't caused me any trouble yet. Signed-off-by: Parag Warudkar parag.l...@gmail.com diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index 2827088..2ba298a 100644

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Mon, 17 Sep 2012, Henrik Rydberg wrote: So the question is, does this patch work equally well for you? diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index 2827088..8bf9011 100644 --- a/drivers/hwmon/applesmc.c +++ b/drivers/hwmon/applesmc.c @@ -56,7 +56,7 @@ /*

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

originally intended I think this patch can only make things better. It sure does make things better on my machine but it will not hurt to test it on other models. Parag Signed-off-by: Parag Warudkar diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index 2827088..a168a8f 1006

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

you could try to use it as a busy indicator, > and use the APPLESMC_RETRY_WAIT for that case. > Henrik - if the below patch still results in failures we can revisit the long wait cases. For now I am satisfied that there aren't any normal case failures like before. Thanks, Parag S

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

- if the below patch still results in failures we can revisit the long wait cases. For now I am satisfied that there aren't any normal case failures like before. Thanks, Parag Signed-off-by: Parag Warudkar parag.l...@gmail.com diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

. It sure does make things better on my machine but it will not hurt to test it on other models. Parag Signed-off-by: Parag Warudkar parag.l...@gmail.com diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index 2827088..a168a8f 100644 --- a/drivers/hwmon/applesmc.c +++ b/drivers/hwmon

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Sat, 15 Sep 2012, Parag Warudkar wrote: > > > On Sat, 15 Sep 2012, Guenter Roeck wrote: > > > > Also, since the delay time can get quite large, would it make sense to > > replace > > udelay with usleep_range() ? > > > > Yes, I think tha

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Sat, 15 Sep 2012, Parag Warudkar wrote: > > Yeah, that would fix the code to match what it says and eliminate most > failures. But in my testing sometimes it needed a max wait of 57344 us - > I wrote a separate patch to instrument it by bumping up max wait in > increments

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Sat, 15 Sep 2012, Guenter Roeck wrote: > On Sat, Sep 15, 2012 at 06:42:30PM -0400, Parag Warudkar wrote: > > I have been getting a steady stream of wait_read timeouts on my 2010 MBP. > > > > After playing around with various values of APPLESMC_MAX_WAIT a value of

[PATCH] applesmc: Bump max wait and rearrange udelay

. While there I noticed we don't really need to udelay before first inb() - so I moved it down to after first and subsequent failures. Been running this for couple days without any issues. Signed-off-by: Parag Warudkar diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index

[PATCH] applesmc: Bump max wait and rearrange udelay

. While there I noticed we don't really need to udelay before first inb() - so I moved it down to after first and subsequent failures. Been running this for couple days without any issues. Signed-off-by: Parag Warudkar parag.l...@gmail.com diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Sat, 15 Sep 2012, Guenter Roeck wrote: On Sat, Sep 15, 2012 at 06:42:30PM -0400, Parag Warudkar wrote: I have been getting a steady stream of wait_read timeouts on my 2010 MBP. After playing around with various values of APPLESMC_MAX_WAIT a value of 0x1 reduces the wait_read

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Sat, 15 Sep 2012, Parag Warudkar wrote: Yeah, that would fix the code to match what it says and eliminate most failures. But in my testing sometimes it needed a max wait of 57344 us - I wrote a separate patch to instrument it by bumping up max wait in increments of 0x2000 until

Re: [PATCH] applesmc: Bump max wait and rearrange udelay

On Sat, 15 Sep 2012, Parag Warudkar wrote: On Sat, 15 Sep 2012, Guenter Roeck wrote: Also, since the delay time can get quite large, would it make sense to replace udelay with usleep_range() ? Yes, I think that would be a good thing to do. We could sleep in range of us=1

[PATCH] Seccomp audit: Reduce unnecessary log spew

hrome" reason="seccomp" sig=0 syscall=2 compat=0 ip=0x7f1a63b45d90 code=0x5 Reduce the seemingly needless repetitive logging by honoring audit_enabled and checking if the signal is worth auditing. Signed-off-by: Parag Warudkar diff --git a/kernel/auditsc.c b/kernel/auditsc.c in

[PATCH] Seccomp audit: Reduce unnecessary log spew

=seccomp sig=0 syscall=2 compat=0 ip=0x7f1a63b45d90 code=0x5 Reduce the seemingly needless repetitive logging by honoring audit_enabled and checking if the signal is worth auditing. Signed-off-by: Parag Warudkar parag.l...@gmail.com diff --git a/kernel/auditsc.c b/kernel/auditsc.c index

Re: Linux Compatible USB Adapter Recommendations? [OT]

On Wed, 13 Feb 2008, Marc Perkel wrote: > I'm looking to buy a wireless USB adapter that I can > plug into a Fedora 8 box. The main feature I want it > to be able to stick it in and have it just work. No > custom kernel compiles. If it had 802.11n that would > be a plus. > > So - what "just

Re: Linux Compatible USB Adapter Recommendations? [OT]

On Wed, 13 Feb 2008, Marc Perkel wrote: I'm looking to buy a wireless USB adapter that I can plug into a Fedora 8 box. The main feature I want it to be able to stick it in and have it just work. No custom kernel compiles. If it had 802.11n that would be a plus. So - what just works

Re: [PATCH] dmi: Prevent linked list corruption (resent)

o in dmi_scan > since commit 79da4721117fcf188b4b007b775738a530f574da. > > Given that there is absolutely no interest in saving empty OEM > strings anyway, I propose the simple and efficient fix below: we > discard the empty OEM strings altogether. > > Signed-off-by: Jean Delvare

Re: [PATCH] dmi: Prevent linked list corruption (resent)

79da4721117fcf188b4b007b775738a530f574da. Given that there is absolutely no interest in saving empty OEM strings anyway, I propose the simple and efficient fix below: we discard the empty OEM strings altogether. Signed-off-by: Jean Delvare [EMAIL PROTECTED] Cc: Parag Warudkar [EMAIL PROTECTED] Cc: Ingo

2.6.25-rc1: Lguest build failure

Hi Rusty Just got this build failure while building -rc1 - Root device is (254, 0) Setup is 12216 bytes (padded to 12288 bytes). System is 1915 kB Kernel: arch/x86/boot/bzImage is ready (#3) Building modules, stage 2. MODPOST 683 modules ERROR: "LGUEST_PAGES_guest_gdt_desc"

2.6.25-rc1: Lguest build failure

Hi Rusty Just got this build failure while building -rc1 - Root device is (254, 0) Setup is 12216 bytes (padded to 12288 bytes). System is 1915 kB Kernel: arch/x86/boot/bzImage is ready (#3) Building modules, stage 2. MODPOST 683 modules ERROR: LGUEST_PAGES_guest_gdt_desc

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Parag Warudkar wrote: > Yep. I will enable PREEMPT and see if it reproduces for me. Not reproducible with PREEMPT either. Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More m

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote: > El Thu, 7 Feb 2008 10:56:16 -0500 (EST) > Parag Warudkar <[EMAIL PROTECTED]> escribió: > > > > > > > On Thu, 7 Feb 2008, Parag Warudkar wrote: > > > > >x86_64

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Parag Warudkar wrote: >x86_64+SMP+PREEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible. > That should of course be x86_64+SMP+PREEMPT+GnuC-4.1.3+Glibc-2.6.1 = Reproducible. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&q

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote: > gcc --version > > gcc-4.2 (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) > > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux Varda 2.6.24 #2

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote: El Thu, 7 Feb 2008 10:56:16 -0500 (EST) Parag Warudkar [EMAIL PROTECTED] escribió: On Thu, 7 Feb 2008, Parag Warudkar wrote: x86_64+SMP+PREEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible. That should of course

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Parag Warudkar wrote: x86_64+SMP+PREEMPT+GnuC-4.1.2+Glibc-2.5 = Reproducible. That should of course be x86_64+SMP+PREEMPT+GnuC-4.1.3+Glibc-2.6.1 = Reproducible. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Thu, 7 Feb 2008, Alejandro Riveira Fernández wrote: gcc --version gcc-4.2 (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux Varda 2.6.24 #2 SMP

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Wed, 6 Feb 2008, Frank Mayhar wrote: > On Wed, 2008-02-06 at 16:50 -0800, Andrew Morton wrote: > > It's probably better to handle this one via email, so please send that > > testcase vie reply-to-all to this email, thanks. > > Testcase attached. > > Build with > gcc -D_GNU_SOURCE

Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

On Wed, 6 Feb 2008, Frank Mayhar wrote: On Wed, 2008-02-06 at 16:50 -0800, Andrew Morton wrote: It's probably better to handle this one via email, so please send that testcase vie reply-to-all to this email, thanks. Testcase attached. Build with gcc -D_GNU_SOURCE -c

Re: LowFree/LowMem problem

Matthias Wolle gmx.de> writes: > > Hi, > > my company is running several servers with kernel 2.6.23.12. This are Dual > Quad Core servers (CPU Intel) with 16GB RAM using a 32Bit kernel. This is a common problem with running 32-bit kernels with more than 8Gb RAM. (Search the archives and you

Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]

On Jan 9, 2008 6:56 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > Can you apply the patch below + the debug patch which prints the timer > stats on softlockup and provide the output of this. Applied to today's git and running for 21 hours - no recurrence yet even with 1.2 wakeups per second.

Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]

On Jan 9, 2008 6:56 AM, Thomas Gleixner [EMAIL PROTECTED] wrote: Can you apply the patch below + the debug patch which prints the timer stats on softlockup and provide the output of this. Applied to today's git and running for 21 hours - no recurrence yet even with 1.2 wakeups per second. I

Re: 2.6.24-rc6-git12: Reported regressions from 2.6.23

On Jan 7, 2008 6:54 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > Well, now you're saying 2.6.23.12 is also affected, so this doesn't seem to > be a recent regression in fact? > I have run 2.6.23 series before but my usage pattern seems to have not triggered the bug before. But yes, this is

Re: 2.6.24-rc6-git12: Reported regressions from 2.6.23

On Jan 6, 2008 2:11 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > On Sunday, 6 of January 2008, Parag Warudkar wrote: > > On Jan 6, 2008 7:57 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > On Sunday, 6 of January 2008, Ingo Molnar wrote: > >

  1   2   3   4   5   >