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 e

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 COMP_STOP_INVAL

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 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 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. > > [0.263398

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 0x0010-0x000

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 efi_lo

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, btw

[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 >>> calls sys

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 sim

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 i

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, 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 [ 56

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 &

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 ev

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 th

[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 Warud

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 x86

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 Williams

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 t

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() i

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 this

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

ieee80211_queue_work(sc->hw, &sc->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-t

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.

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] [] warn_slowp

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'

[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 an

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/

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

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

e same 32 ms max wait as 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 in

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

hange occasionally, 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

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 w

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 &g

[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

[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

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 wo

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

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" [drivers/lguest/l

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 majo

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"

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 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 wil

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: 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: > >

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

On Jan 6, 2008 7:57 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > On Sunday, 6 of January 2008, Ingo Molnar wrote: > > > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > > Subject : soft lockup - CPU#1 stuck for 15s! [swapper:0] &g

Re: memory remapping, 4gb memory on 945gt

H. Peter Anvin zytor.com> writes: > > Supposedly WinXP-32 doesn't use memory over 4 GB even if it is available > (a market-segmentation decision of the part of Microsoft, to force > people to buy WinServer 2003; WinXP SP2 does PAE so there is no > technical reason.) This probably has disince

Re: kernel BUG at fs/buffer.c:1245!

nokia.com> writes: > > > Hi > > I am running 2.6.23 kernel on i386. Sometimes during reboot or file read > write > I get this kernel crash. .config attached. > > kernel BUG at fs/buffer.c:1245! > invalid opcode: [#1] > SMP > Modules linked in: sfpacket(PF) e1000 adm1026 hwmon_vid noksf

Re: [PATCH] x86: Fix DMI out of memory problems

On Fri, 21 Dec 2007, Andi Kleen wrote: > > FWIW the ff tree has patches to allow "really early allocation" now. > They could be used for this. I didn't implement that for i386 though, > so that would still need some variant of your patch. Just to clarify -The allocation failure currently happe

Re: [PATCH] sky2: Use deferrable timer for watchdog

On Dec 20, 2007 3:04 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > I think it is reasonable for Network driver watchdogs to use a > > deferrable timer - if the machine is 100% IDLE there is no one needing > > the network to be up. If there is something running even on the other > > CPU - that

Re: [PATCH] sky2: Use deferrable timer for watchdog

On Dec 20, 2007 2:22 PM, Kok, Auke <[EMAIL PROTECTED]> wrote: > ok, that's just bad and if there's no user-defineable limit to the deferral I > definately don't like this change. > > Can I safely assume that any irq will cause all deferred timers to run? I think even other causes for wakeup like p

Re: [PATCH] sky2: Use deferrable timer for watchdog

On Dec 20, 2007 12:51 PM, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > Quit top-posting! > > If this is the case then the whole usage of round_jiffies() is bogus. All > users of round_jiffies() > should just be converted to deferrable?? I am a bit concerned that if > deferrable gets used eve

Re: [PATCH] e1000e: Use deferrable timer for watchdog

On Dec 20, 2007 12:05 PM, Kok, Auke <[EMAIL PROTECTED]> wrote: > > I can't even apply this patch and the e1000 one... not only is it whitespace > damaged it is also not properly formatted as patch at all. If you want me to > take > these patches seriously, then please fix the formatting issues. S

Re: [PATCH] e1000: Use deferrable timer for watchdog

On Dec 19, 2007 4:38 PM, Kok, Auke <[EMAIL PROTECTED]> wrote: > Parag Warudkar wrote: > > On 12/19/07, Kok, Auke <[EMAIL PROTECTED]> wrote: > > why would this patch reduce wakeups even more than round_jiffies()? Does it > make > our ~2 second update interval not

Re: [PATCH] e1000: Use deferrable timer for watchdog

time and haven't seen any problem at all and powertop shows it reduces the wakeups-from-idle. But whatever - no big deal since it already uses round_jiffies(). Parag > > > > Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> > > > > --- linux-2.6/drive

Re: [PATCH] x86: Fix DMI out of memory problems

On Dec 19, 2007 12:06 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > Here is the right one - > > 2.6.24-rc5 is without patch, 2.6.24-rc5-new is with patch. > > > DMI present. > > -dmi_save_oem_stri

Re: [PATCH] x86: Fix DMI out of memory problems

On Dec 19, 2007 11:54 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > --- 2.6.24-rc5-patched2007-12-19 07:21:05.0 -0500 > > +++ 2.6.24-rc5-new2007-12-19 11:36:54.0 -0500 > > hm, i se

Re: [PATCH] x86: Fix DMI out of memory problems

On Dec 19, 2007 5:48 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > [ note: i had to manually fix up your patch because your email client > added an extra space to every diff line - see > Documentation/email-clien

Re: Out of memory and no killable processes: 2.6.22-2-686-bigmem

On Wed, 19 Dec 2007, Nico Schottelius wrote: If you're running tons of memory, it really is better to run a 64-bit kernel if possible. Sure? Afaik that results in a bit slower access to memory and appart from being able to address MUCH more memory doesn't change the situation. No, generally

[PATCH] e1000e: Use deferrable timer for watchdog

Reduce wakeups from idle per second. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/drivers/net/e1000e/netdev.c 2007-12-07 10:04:39.0 -0500 +++ linux-2.6-work/drivers/net/e1000e/netdev.c 2007-12-18 20:45:59.0 -0500 @@ -3899,7 +

[PATCH] e1000: Use deferrable timer for watchdog

Use deferrable timer for watchdog. Reduces wakeups from idle per second. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/drivers/net/e1000/e1000_main.c2007-12-07 10:04:39.0 -0500 +++ linux-2.6-work/drivers/net/e1000/e1000_main.c 2007-12-18 20:38:38.000

[PATCH] sky2: Use deferrable timer for watchdog

sky2 can use deferrable timer for watchdog - reduces wakeups from idle per second. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/drivers/net/sky2.c2007-12-07 10:04:39.0 -0500 +++ linux-2.6-work/drivers/net/sky2.c 2007-12-18 20:07:58.0

[PATCH] sch_generic.c: Make dev_watchdog use deferrable timer

Reduces the number of wakeups from idle per second, makes powertop happy. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/net/sched/sch_generic.c 2007-12-07 10:04:43.0 -0500 +++ linux-2.6-work/net/sched/sch_generic.c 2007-12-16 17:57:05.0 -0500 @@

[PATCH] clocksource.c: Use init_timer_deferrable for clocksource_watchdog

clocksource_watchdog can use a deferrable timer - reduces wakeups from idle per second. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/kernel/time/clocksource.c 2007-12-07 10:04:43.0 -0500 +++ linux-2.6-work/kernel/time/clocksource.c2007-12-13 12:49:14.000

[PATCH] x86: Fix dmi_alloc() to not advance alloc index in case of failure

the array. Fix this by first testing if allocation is going to be possible and incrementing alloc index only then. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/include/asm-x86/dmi.h 2007-12-07 10:04:42.0 -0500 +++ linux-2.6-work/include/asm-x86

[PATCH] x86: Fix DMI out of memory problems

should save a good amount of (27*65 bytes + 27*sizeof(struct dmi_device) bootmem. Compile and boot tested on both x86 and x86_64. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6/drivers/firmware/dmi_scan.c 2007-12-07 10:04:38.0 -0500 +++ linux-2.6-work/drivers/fi

Re: init_timer_deferrable conversion

On Dec 17, 2007 9:29 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote: > Parag, could you please try this patch ? > > [NET] ARP : Convert neigh garbage collection from softirq to workqueue > I will - a little later. Thanks Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel

Re: init_timer_deferrable conversion

On Dec 17, 2007 12:00 PM, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > > > > > > a) drivers/net/sky2.c - watchdog_timer. This was showing up high on > > > > Powertop's list of things that cause routine wakeups from idle. After > > > > converting to init_timer_deferrable() the wakeups went dow

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

On Dec 17, 2007 3:05 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > On Sun, 16 Dec 2007, Parag Warudkar wrote: > > > On Dec 16, 2007 12:15 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > On Sat, 15 Dec 2007, Parag Warudkar wrote: > > > > >

init_timer_deferrable conversion

In my quest to get the wake-ups from idle per second down to bare minimum, I noticed 3 places in the kernel that could benefit from using init_timer_deferrable() instead of init_timer() - a) drivers/net/sky2.c - watchdog_timer. This was showing up high on Powertop's list of things that cause r

Re: [PATCH] [RFC] be more verbose when probing EDD

On Dec 16, 2007 2:11 PM, <[EMAIL PROTECTED]> wrote: > some of them > http://forums.suselinuxsupport.de/lofiversion/index.php/t61581.html > http://suseforums.net/index.php?showtopic=1302 > http://forums.suselinuxsupport.de/lofiversion/index.php/t3157.html > http://www.linuxforums.org/forum/installa

Re: [PATCH] [RFC] be more verbose when probing EDD

On Sun, 16 Dec 2007, [EMAIL PROTECTED] wrote: - it seems there are buggy Bios implementations out there which have problems with EDD - your favourite distro may have set CONFIG_EDD=y|m , so EDD probe is on by default quite often nowadays. - setting "edd=off" when you get that hang on boot is

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

On Dec 16, 2007 12:15 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote: > On Sat, 15 Dec 2007, Parag Warudkar wrote: > > >> I will run it for a little longer just to be sure - but I don't think it > >> will be a problem. > > No problems for last 10 hours -

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

On Sat, 15 Dec 2007, Parag Warudkar wrote: I will run it for a little longer just to be sure - but I don't think it will be a problem. No problems for last 10 hours - I consider this fixed. Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

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

On Sat, 15 Dec 2007, Thomas Gleixner wrote: I have a patch staged for Linus, which fixes a thinko in the broadcast code. It might be related to your problem. Can you give it a try ? Yep - this looks promising. No soft lockups for last half an hour with 4-5 Wakeups from idle. It is almost smoo

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

On Dec 14, 2007 6:17 PM, Len Brown <[EMAIL PROTECTED]> wrote: > does processor.max_cstate=1 make the failing configuration work? > If yes, how about processor.max_cstate=2? Until now 2 things were necessary to reproduce the problem - 1) CPU_IDLE=y and 2) Wakeups from Idle = 5-7 Per second (== Long

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

On Dec 8, 2007 6:12 PM, Parag Warudkar <[EMAIL PROTECTED]> wrote: > No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE > and CONFIG_NO_HZ. > > I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last - > that way we can at least tell what is require

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

No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE and CONFIG_NO_HZ. I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last - that way we can at least tell what is required to be hit with this problem. Parag -- To unsubscribe from this list: send the line "unsubscribe

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

On Dec 8, 2007 3:51 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > what chipset is this? > (I wonder if there's one where we shouldn't be force-enabling the hpet) It's an Intel Mac Mini - Intel 945GM chipset. I believe OSX requires HPET and so there shouldn't be a need to force enable it on thi

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

On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > But there are still fluctuations under 100% idle - > > do you have CONFIG_HIGH_RES_TIMERS=y? Yes - NO_HZ=y and HIGH_RES_TIMERS=y. My ssh connec

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

On Dec 8, 2007 2:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > Even on 100% idle I get variations that are approx in the same range > > when not idle. Clocksource is hpet if that matters. Next I think I &g

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

On Dec 8, 2007 2:13 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > >while :; do time usleep 111; done > > > > > > or do these sleeps fluctuate? > > > > They seem to fluctua

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

On Dec 8, 2007 10:47 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > does the patch below help? But the root cause is likely some timer > problems - do you get consistent results from: > Haven't yet tried the patch - will try a little later. >while :; do time usleep 111; done > > or do the

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

On Dec 8, 2007 10:10 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote: > On Dec 7, 2007 9:56 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > > This looks pretty much like the problem I was solving yesterday. > > > > Parag, can you please try Linus latest

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

On Dec 7, 2007 9:56 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > This looks pretty much like the problem I was solving yesterday. > > Parag, can you please try Linus latest and please check whether there > is a stack trace with clockevents_program_event on the top in your > dmesg. > Just boo

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

On Dec 7, 2007 6:12 PM, Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote: > Looks like tick_broadcast_lock did not get freed in some path. > You do not see this when you CPU_IDLE is not configured? > > Thanks, > Venki > No, I did not see this prior to enabling CPU_IDLE. All previous kernels withou

Re: new card to me?

Gene Heskett gmail.com> writes: > > Greetings; > > Is this drive interface card supported by the current linux kernel? > > Masscool XWT-RC018, as seen on tigerdirect's site: > > > > Thank you. >

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

Got this on today's git (2.6.24-rc4) while compiling stuff - Looks like it is related to CpuIdle stuff. I chose CONFIG_CPU_IDLE for the first time so I don't know when this was introduced. This is on x86_32, SMP. BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] Pid: 0, comm: swapper Not tain

Re: Failure with SATA DVD-RW

Tom Lanyon gmail.com> writes: > scsi4: ahci > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > ata5.00: ATAPI, max UDMA/66 > ata5.00: qc timeout (cmd 0xef) > ata5.00: failed to set xfermode (err_mask=0x104) > ata5.00: limiting speed to UDMA/44 > ata5: failed to recover some devices, re

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

Hi Ivo On Thu, 25 Oct 2007, Ivo van Doorn wrote: I awknowledge the problem, but the solution cannot be found in the USB ID's listed in the driver. The bug is the manufacturer who changed chipset while keeping the USB ID the same. There are 2 possible ways around this: hacking the module loader

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

On Thu, 25 Oct 2007, Adam Baker wrote: Unfortunately Belkin have sold both RT73 and RT2500 devices with that USB ID. You don't say what distro you are runing or what version of RT2x00 it ships with but last time I checked with the git version of rt2x00 it tried to load both drivers but the rt

[PATCH] rt2500usb - Don't claim 050d:705{0/a}

to be handled by both rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no way to be sure as I don't have device with this ID) the following patch makes sure only rt73usb claims the 2 devices. Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]> --- linux-2.6-wk/

  1   2   3   >