- 04 Nov, 2006 9 commits
-
-
Takashi Iwai authored
Fixed Oops when conflictin with aoa driver due to lack of i2c initialization. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Arnaud Patard authored
The emu10k1 driver saves the A_IOCFG and HCFG register on suspend and restores it on resumes. Unfortunately, this doesn't work as the arguments to outl() are reversed. From: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by:
Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by:
-
Stephen Hemminger authored
When PHY is turned off on shutdown, it can causes the IRQ to get stuck on. Make sure and disable the IRQ first, and if IRQ occurs when device is not running, don't access PHY because that can hang. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Stephen Hemminger authored
The lower pause threshold set by the driver is too large and causes FIFO overruns. Especially on laptops running at slower clock rates. Signed-off-by:
-
Stephen Hemminger authored
Make sure and do PCI reads after writes in the MSI test setup code. Some motherboards don't implement MSI correctly. The driver handles this but the warning is too verbose and overly cautious. Signed-off-by:
-
Suresh Siddha authored
Failing context is a multi threaded process context and the failing sequence is as follows. One thread T0 doing self modifying code on page X on processor P0 and another thread T1 doing COW (breaking the COW setup as part of just happened fork() in another thread T2) on the same page X on processor P1. T0 doing SMC can endup modifying the new page Y (allocated by the T1 doing COW on P1) but because of different I/D TLB's, P0 ITLB will not see the new mapping till the flush TLB IPI from P1 is received. During this interval, if T0 executes the code created by SMC it can result in an app error (as ITLB still points to old page X and endup executing the content in page X rather than using the content in page Y). Fix this issue by first clearing the PTE and flushing it, before updating it with new entry. Hugh sayeth: I was a bit sceptical, in the habit of thinking that Self Modifying Code must look such issues itself: but I guess there's nothing it can do to avoid this one. Fair enough, what you're changing it to is pretty much what powerpc and s390 were already doing, and is a more robust way of proceeding, consistent with how ptes are set everywhere else. The ptep_clear_flush is a bit heavy-handed (it's anxious to return the pte that was atomically cleared), but we'd have to wander through lots of arches to get the right minimal behaviour. It'd also be nice to eliminate ptep_establish completely, now only used to define other macros/inlines: it always seemed obfuscation to me, what you've got there now is clearer. Let's put those cleanups on a TODO list. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
"David S. Miller" <davem@davemloft.net> Acked-by:
Hugh Dickins <hugh@veritas.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Martin Schwidefsky authored
The clocksource infrastructure introduced with commit ad596171 broke 31 bit s390. The reason is that the do_div() primitive for 31 bit always had a restriction: it could only divide an unsigned 64 bit integer by an unsigned 31 bit integer. The clocksource code now uses do_div() with a base value that has the most significant bit set. The result is that clock->cycle_interval has a funny value which causes the linux time to jump around like mad. The solution is "obvious": implement a proper __div64_32 function for 31 bit s390. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Jens Axboe authored
Don't jump to the unlock+release path, we already did that. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Patrick McHardy authored
Dave Jones wrote: > sfuzz D 724EF62A 2828 28717 28691 (NOTLB) > cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0 > dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202 > de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0 > Call Trace: > [<c05b1708>] lock_sock+0x75/0xa6 > [<e0b0b604>] dn_getname+0x18/0x5f [decnet] > [<c05b083b>] sys_getsockname+0x5c/0xb0 > [<c05b0b46>] sys_socketcall+0xef/0x261 > [<c0403f97>] syscall_call+0x7/0xb > DWARF2 unwinder stuck at syscall_call+0x7/0xb > > I wonder if the plethora of lockdep related changes inadvertantly broke something? Looks like unbalanced locking. Acked-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
- 14 Oct, 2006 1 commit
-
-
Greg Kroah-Hartman authored
-
- 13 Oct, 2006 30 commits
-
-
Dave Jones authored
Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Sascha Hauer authored
This patch fixes a copy-paste bug in videodev.c where the vidioc_qbuf() function gets called for the dqbuf ioctl. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Vasily Tarasov authored
elv_iosched_show function iterates other elv_list, hence elv_list_lock should be got. Also the question is: in elv_iosched_show, elv_iosched_store q->elevator->elevator_type construction is used without locking q->queue_lock. Is it expected?.. Signed-off-by:
Vasily Tarasov <vtaras@openvz.org> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Patrick McHardy authored
The whole idea with the NOTRACK netfilter target is that you can force the netfilter code to avoid connection tracking, and all costs assosciated with it, by making traffic match a NOTRACK rule. But this is totally broken by the fact that we do a checksum calculation over the packet before we do the NOTRACK bypass check, which is very expensive. People setup NOTRACK rules explicitly to avoid all of these kinds of costs. This patch from Patrick, already in Linus's tree, fixes the bug. Move the check for ip_conntrack_untracked before the call to skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19 NAT code breaks TSO by invalidating hardware checksums for every packet, even if explicitly excluded from NAT through NOTRACK. 2.6.19 includes a fix that makes NAT and TSO live in harmony, but the performance degradation caused by this deserves making at least the workaround work properly in -stable. Signed-off-by:
-
Larry Finger authored
The bcm43xx code in 2.6.18 has a serious problems not found in 2.6.17, due to a change in the locking mechanism introduced to reduce latency. The following patch fixes the problems in locking, reduces the latency associated with the periodic work tasklet, and contains code needed for those cards that use 64-bit DMA. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Jon Mason authored
This patch has already been submitted for inclusion in the 2.6.19 tree, but not backported to the 2.6.18. Please pull the bug fix below into the stable tree for the 2.6.18.1 release. The purpose of the code being modified is to determine the location of the calgary chip address space. This is done by a magical formula of FE0MB-8MB*OneBasedChassisNumber+1MB*(RioNodeId-ChassisBase) to find the offset where BIOS puts it. In this formula, OneBasedChassisNumber corresponds to the NUMA node, and rionodeid is always 2 or 3 depending on which chip in the system it is. The problem was that we had an off by one error that caused us to account some busses to the wrong chip and thus give them the wrong address space. Fixes RH bugzilla #203971. Signed-off-by:
Jon Mason <jdmason@kudzu.us> Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Signed-off-by:
-
Alan Cox authored
Some people find their Jmicron pata port reports its disabled even though it has devices on it and was boot probed. Fix this (Candidate for 2.6.18.*, less so for 2.6.19 as we've got a proper jmicron driver on the merge for that to replace ide-generic support) From: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Jim Cromie authored
Fix paren-placement / precedence bug breaking initialization for 1 MHz clock mode. Also fix comment spelling error, and fence-post (off-by-one) error on symbol used in request_region. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=7242 Thanks alexander.krause@erazor-zone.de, dzpost@dedekind.net, for the reports and patch test, and phelps@mantara.com for the independent patch and verification. Signed-off-by:
Jim Cromie <jim.cromie@gmail.com> Cc: <alexander.krause@erazor-zone.de> Cc: <dzpost@dedekind.net> Cc: <phelps@mantara.com> Acked-by:
John Stultz <johnstul@us.ibm.com> Signed-off-by:
-
Andrew Morton authored
The recent fix to invalidate_inode_pages() (git commit 016eb4a0) managed to unfix invalidate_inode_pages2(). The problem is that various bits of code in the kernel can take transient refs on pages: the page scanner will do this when inspecting a batch of pages, and the lru_cache_add() batching pagevecs also hold a ref. Net result is transient failures in invalidate_inode_pages2(). This affects NFS directory invalidation (observed) and presumably also block-backed direct-io (not yet reported). Fix it by reverting invalidate_inode_pages2() back to the old version which ignores the page refcounts. We may come up with something more clever later, but for now we need a 2.6.18 fix for NFS. Cc: Chuck Lever <cel@citi.umich.edu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Jean-Baptiste Maneyrol authored
The century bit PCF8563_MO_C in the month register is misinterpreted. It is set to 1 for the 20th century and 0 for 21th, and the driver is expecting the opposite behavior. Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Geert Uytterhoeven authored
Address http://bugzilla.kernel.org/show_bug.cgi?id=7189 It should check `clen', not `len'. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: <jurij@wooyd.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Nick Piggin authored
This was triggered, but not the fault of, the dirty page accounting patches. Suitable for -stable as well, after it goes upstream. Unable to handle kernel NULL pointer dereference at virtual address 0000004c EIP is at _spin_lock+0x12/0x66 Call Trace: [<401766e7>] __set_page_dirty_buffers+0x15/0xc0 [<401401e7>] set_page_dirty+0x2c/0x51 [<40140db2>] set_page_dirty_balance+0xb/0x3b [<40145d29>] __do_fault+0x1d8/0x279 [<40147059>] __handle_mm_fault+0x125/0x951 [<401133f1>] do_page_fault+0x440/0x59f [<4034d0c1>] error_code+0x39/0x40 [<08048a33>] 0x8048a33 ======================= Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
David Miller authored
This changes the microsecond RTT sampling so that samples are taken in the same way that RTT samples are taken for the RTO calculator: on the last segment acknowledged, and only when the segment hasn't been retransmitted. Signed-off-by:
John Heffner <jheffner@psc.edu> Acked-by:
-
Neil Brown authored
If a drive is added with HOT_ADD_DISK rather than ADD_NEW_DISK, saved_raid_disk isn't initialised properly, and the drive can be included in the array without a resync. From: Neil Brown <neilb@suse.de> Cc: <syrius.ml@no-log.org> Cc: Richard Bollinger <rabollinger@gmail.com> Signed-off-by: -
David Miller authored
Because the system won't turn off the SG flag for us we need to do this manually on the IPv6 path. Otherwise we will throw IPv6 packets with bad checksums at the hardware. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
David Miller authored
gcc-4.1 and later take advantage of the fact that in the C language certain types of overflow/underflow are undefined, and this is completely legitimate. Prevents filters from being added if the first generated handle already exists. Signed-off-by:
Kim Nordlund <kim.nordlund@nokia.com> Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Jeff Garzik authored
From: Jeff Garzik <jeff@garzik.org> Signed-off-by: -
David S. Miller authored
[SPARC64]: Kill bogus check from bootmem_init(). There is an ancient and totally incorrect sanity check being done on the ramdisk location. The check assumes that the kernel is always loaded to physical address zero, which is wrong. It was trying to validate the ramdisk value by saying that if it fell within the kernel image address range it must be wrong. Anyways, kill this because it actually creates problems. The 'ramdisk_image' should always be adjusted down by KERNBASE. SILO can easily put the ramdisk in a location which causes this test to trigger, breaking things. [ Based almost entirely upon a patch from Ben Collins. ] Signed-off-by:
-
Fabio Olive Leite authored
A while ago Ingo patched tcp_v4_rcv on net/ipv4/tcp_ipv4.c to use bh_lock_sock_nested and silence a lock validator warning. This fixed it for IPv4, but recently I saw a report of the same warning on IPv6. Signed-off-by:
-
Dave Jones authored
[CPUFREQ] Fix some more CPU hotplug locking. Lukewarm IQ detected in hotplug locking BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug() [<b0134a42>] lock_cpu_hotplug+0x42/0x65 [<b02f8af1>] cpufreq_update_policy+0x25/0xad [<b0358756>] kprobe_flush_task+0x18/0x40 [<b0355aab>] schedule+0x63f/0x68b [<b01377c2>] __link_module+0x0/0x1f [<b0119e7d>] __cond_resched+0x16/0x34 [<b03560bf>] cond_resched+0x26/0x31 [<b0355b0e>] wait_for_completion+0x17/0xb1 [<f965c547>] cpufreq_stat_cpu_callback+0x13/0x20 [cpufreq_stats] [<f9670074>] cpufreq_stats_init+0x74/0x8b [cpufreq_stats] [<b0137872>] sys_init_module+0x91/0x174 [<b0102c81>] sysenter_past_esp+0x56/0x79 As there are other places that call cpufreq_update_policy without the hotplug lock, it seems better to keep the hotplug locking at the lower level for the time being until this is revamped. Signed-off-by:
-
David S. Miller authored
Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 --> 128" bit multiply like PowerPC and IA64 do. We were doing a "64 X 64 --> 64" bit multiple which causes overflow very quickly with a 30-bit quotient shift. So use a quotientshift count of 10 instead of 30, just like x86 and ARM do. This also fixes the wrapping of printk timestamp values every ~17 seconds. Signed-off-by:
-
Jonathan Corbet authored
The v4l2 API documentation for VIDIOC_ENUMSTD says: To enumerate all standards applications shall begin at index zero, incrementing by one until the driver returns EINVAL. The actual code, however, tests the index this way: if (index<=0 || index >= vfd->tvnormsize) { ret=-EINVAL; So any application which passes in index=0 gets EINVAL right off the bat - and, in fact, this is what happens to mplayer. So I think the following patch is called for, and maybe even appropriate for a 2.6.18.x stable release. Signed-off-by:Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Ed Swierk authored
Invoking load_module() before param_sysfs_init() is called crashes in mod_sysfs_setup(), since the kset in module_subsys is not initialized yet. In my case, net-pf-1 is getting modprobed as a result of hotplug trying to create a UNIX socket. Calls to hotplug begin after the topology_init initcall. Another patch for the same symptom (module_subsys-initialize-earlier.patch) moves param_sysfs_init() to the subsys initcalls, but this is still not early enough in the boot process in some cases. In particular, topology_init() causes /sbin/hotplug to run, which requests net-pf-1 (the UNIX socket protocol) which can be compiled as a module. Moving param_sysfs_init() to the postcore initcalls fixes this particular race, but there might well be other cases where a usermodehelper causes a module to load earlier still. The patch makes load_module() return an error rather than crashing the kernel if invoked before module_subsys is initialized. Cc: Mark Huang <mlhuang@cs.princeton.edu> Signed-off-by:
-
keith mannthey authored
If there is only 1 node in the system cpus should think they are apart of some other node. If cases where a real numa system boots the Flat numa option make sure the cpus don't claim to be apart on a non-existent node. Signed-off-by:
Keith Mannthey <kmannth@us.ibm.com> Cc: Andy Whitcroft <apw@shadowen.org> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Assume that a cpu is *physically* offlined at boot time... Because smpboot.c::smp_boot_cpu_map() canoot find cpu's sapicid, numa.c::build_cpu_to_node_map() cannot build cpu<->node map for offlined cpu. For such cpus, cpu_to_node map should be fixed at cpu-hot-add. This mapping should be done before cpu onlining. This patch also handles cpu hotremove case. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Problem description: We have additional_cpus= option for allocating possible_cpus. But nid for possible cpus are not fixed at boot time. cpus which is offlined at boot or cpus which is not on SRAT is not tied to its node. This will cause panic at cpu onlining. Usually, pxm_to_nid() mapping is fixed at boot time by SRAT. But, unfortunately, some system (my system!) do not include full SRAT table for possible cpus. (Then, I use additiona_cpus= option.) For such possible cpus, pxm<->nid should be fixed at hot-add. We now have acpi_map_pxm_to_node() which is also used at boot. It's suitable here. Signed-off-by:
-
Michael Hanselmann authored
Seems like not all drivers use the framebuffer_alloc() function and won't have an initialized mutex. But those don't have a backlight, anyway. Signed-off-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Cc: Olaf Hering <olaf@aepfle.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Daniel R Thompson <daniel.thompson@st.com> Cc: Jon Smirl <jonsmirl@gmail.com> Signed-off-by:
-
David Rientjes authored
Stops panic associated with attempting to free a non slab-allocated per_cpu_pageset. Signed-off-by:
David Rientjes <rientjes@cs.washington.edu> Acked-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Peter Zijlstra authored
BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted) [<c04051ee>] show_trace_log_lvl+0x58/0x171 [<c0405802>] show_trace+0xd/0x10 [<c040591b>] dump_stack+0x19/0x1b [<c043abee>] trace_hardirqs_on+0xa2/0x11e [<c06143c3>] _spin_unlock_irq+0x22/0x26 [<c0541540>] rtc_get_rtc_time+0x32/0x176 [<c0419ba4>] hpet_rtc_interrupt+0x92/0x14d [<c0450f94>] handle_IRQ_event+0x20/0x4d [<c0451055>] __do_IRQ+0x94/0xef [<c040678d>] do_IRQ+0x9e/0xbd [<c0404a49>] common_interrupt+0x25/0x2c DWARF2 unwinder stuck at common_interrupt+0x25/0x2c Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
keith mannthey authored
With CONFIG_PHYSICAL_START set to a non default values the i386 boot_ioremap code calculated its pte index wrong and users of boot_ioremap have their areas incorrectly mapped (for me SRAT table not mapped during early boot). This patch removes the addr < BOOT_PTE_PTRS constraint. Signed-off-by: Keith Mannthey<kmannth@us.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
