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

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

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

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

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

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

[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

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

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

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

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

[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

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

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

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

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

[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

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

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

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

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

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

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

How to find if BIOS has already enabled the device

> On Sad, 2005-05-28 at 14:57, Parag Warudkar wrote: > > This current problem of Hang-On-Boot if USB drive is attached does not happen > > with Windows - so it is some sort of additional (unnecessary?) thing which > > Linux does and the BIOS doesn't like. (Like re-ena

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

On Thursday 14 July 2005 20:38, Andi Kleen wrote: > It's basically impossible to regression test swsusp except to release it. > Its success or failure depends on exactly the driver > combination/platform/BIOS version etc.  e.g. all drivers have to cooperate > and the particular bugs in your BIOS ne

Re: Lost Ticks on x86_64

> No way to fix this, but you can work around it with very new kernels > by compiling with a lower HZ than 1000. John Stultz's timeofday patches seem to fix this lost ticks issue. You might want to try them. (I too, routinely get "lost ticks - rip is at acpi_processor_idle" messages which vani

2.6.13-rc6-git5 : PCI mem resource alloc failure

With 2.6.13-rc6-git5 I started getting the below errors. Despite of the errors everything works fine. (only problem is that I have to disconnect /reconnect the usb mouse for it to get detected..) [0.00] Allocating PCI resources starting at 6000 (gap: 6000:9ff8) . . . [ 47.88

Re: 2.6.13-rc6-git5 : PCI mem resource alloc failure == PCMCIA Busted

On Sat, 2005-08-13 at 21:27 -0400, Parag Warudkar wrote: > With 2.6.13-rc6-git5 I started getting the below errors. Despite of the > errors everything works fine. (only problem is that I have to > disconnect /reconnect the usb mouse for it to get detected..) Another problem is that

2.6.12 - USB Mouse not detected

Beginning 2.6.12 my Wireless USB Mouse is not detected in the first attempt - Meaning if I boot the machine with the mouse connected, it's not detected until I disconnect the mouse and then reconnect it. It works fine after the disconnect-reconnect cycle. Looking at the dmesg, it seems that at f

Re: [linux-usb-devel] 2.6.12 - USB Mouse not detected

On Sunday 10 July 2005 16:42, Alan Stern wrote: > > Beginning 2.6.12 my Wireless USB Mouse is not detected in the first > > attempt - Meaning if I boot the machine with the mouse connected, it's > > not detected until I disconnect the mouse and then reconnect it. > > That's not quite right.  Your l

Re: PROBLEM: "drive appears confused" and "irq 18: nobody cared!"

On Friday 29 July 2005 20:57, Michael Thonke wrote: > Hello Alexander, > > do you run > A.) SATA in Enhanced Mode > B.) SATA+PATA or PATA operation mode? > > This problem I can reproduce when I  set A.)+B.) in bios I > exactly get the same behavior of confused cd - drives. > > Greets > > Best regar

Re: pci cacheline size / latency oddness.

On Mon, 2005-08-01 at 19:35 -0400, Dave Jones wrote: > This means we will do the wrong thing on AMD machines which have > 64 byte cachelines. pcibios_init (in i386/pci/common.c, which is linked in by X86_64 PCI code) seems to do this if (c->x86 >= 6 && c->x86_vendor == X86_VENDOR_AMD)

Re: kernel BUG at kernel/workqueue.c:104!

Karl Hiramoto hiramoto.org> writes: > > Hi, i get this a lot now when doing: "rmmod cp2101 io_edgeport " > > I try and do the rmmod, because i loose comunications on the USB to > RS-232 adapters. > [ cut here ] > kernel BUG at kernel/workqueue.c:104! > invalid operan

Re: process creation time increases linearly with shmem

> Ray Fucillo <[EMAIL PROTECTED]> writes: > > > > The application is a database system called Caché. We allocate a > > large shared memory segment for database cache, which in a large > > production environment may realistically be 1+GB on 32-bit platforms > > and much larger on 64-bit. At these

Re: process creation time increases linearly with shmem

On Thu, 2005-08-25 at 16:22 +0200, Andi Kleen wrote: > But I'm not sure it's a good idea in all cases. Would need a lot of > benchmarking at least. > > -Andi > Exactly - one problem is that this forces all of the hugetlb users to go the lazy faulting way. This is more or less similar to the or

Re: [PATCH 1/3] Updated dynamic tick patches - Fix lost tick calculation in timer_pm.c

Lee Revell wrote: Are lost ticks really that common? If so, any idea what's disabling interrupts for so long (or if it's a hardware issue)? And if not, it seems like you'd need an artificial way to simulate lost ticks in order to test this stuff. Lee Yes - I know many people with laptops w

Re: 2.6.11.11 and rsync oops (SATA related?)

Jesper Juhl wrote: It seems you forgot to include the data. Nothing inline in the email, nor any attachments. I could see the attachments and inline dmesg - probably your mail server is at it. Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: Immediate general protection errors on Tyan board

Bob Richmond wrote: Immediately upon boot on this system, most userland programs will segfault, including mount. This causes the system to come up in a bizarre state with the root filesystem mounted read-only, and nothing runs without segfault. There have been numerous similar posts about thi

2.6.13-mm1 X86_64: All 32bit programs segfault

I am clueless as to what's going on but just raising a flag in case it is a not yet known problem. Thunderbird, 32bit Sun Java and Opera are the ones I tried. They all work fine with the Fedora 2.6.12-x kernel but consistently seg fault with 2.6.13-mm1. Parag Sample stack trace for jav

Re: 2.6.13-mm1 X86_64: All 32bit programs segfault

Andi Kleen wrote: Hmm - not many x86-64 patches in mm1. 2.6.13 definitely works. 2.6.13-git7 works. So something in -mm has gone bad (if not x86_64, may be i386 or arch-independent changes?) It seems it has got something to do with the sys_set_tid_address as evident from the strace output b

Re: 2.6.13-mm1 X86_64: All 32bit programs segfault

Andrew Morton wrote: it works fine. I can't reproduce this with the current -mm lineup. I compiled up a 32-bit app on x86 and transferred that across. Maybe it got fixed. Please test 2.6.13-mm2, which appears to be an hour or two away. If it still fails then I'd need a recipe (includi

Re: 2.6.13-mm1 X86_64: All 32bit programs segfault

Andi Kleen wrote: If you catch a crash in gdb and type x/i $pc what do you see? -Andi Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1431820864 (LWP 2839)] 0x00c40471 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 (gdb) x/i $pc 0xc40471 <_

Re: 2.6.13-mm2

Andrew Morton wrote: Parag, perhaps you could confirm that reverting that patch fixes things up? Sure - reverting the x86-64-ptrace-ia32-bp-fix patch fixes it. Roland - if seeing backtraces and register info for the failing programs is going to help you, please see the thread "2.6.13-mm1 X8

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

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

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

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

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

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

[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

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

  1   2   3   >