aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Linux 2.6.24-rc8v2.6.24-rc8Linus Torvalds2008-01-15
|
* [IA64] Fix unaligned handler for floating point instructions with base updateLuck, Tony2008-01-15
| | | | | | | | | | | | | | | | | | | | | | The compiler team did the hard work for this distilling a problem in large fortran application which showed up when applied to a 290MB input data set down to this instruction: ldfd f34=[r17],-8 Which they noticed incremented r17 by 0x10 rather than decrementing it by 8 when the value in r17 caused an unaligned data fault. I tracked it down to some bad instruction decoding in unaligned.c. The code assumes that the 'x' bit can determine whether the instruction is an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on page 3:302 of the SDM). But for opcode=7 the 'x' bit is irrelevent, all variants are "ldf" instructions (see table 4-36 on page 3:306). Note also that interpreting the instruction as "ldfp" means that the "paired" floating point register (f35 in the example here) will also be corrupted. Signed-off-by: Tony Luck <tony.luck@intel.com>
* Merge branch 'upstream-linus' of ↵Linus Torvalds2008-01-15
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata: correct handling of TSS DVD [libata] core checkpatch fix [libata] pata_bf54x: checkpatch fixes libata fixes for sparse-found problems
| * libata: correct handling of TSS DVDAlan Cox2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | Devices that misreport the validity bit for word 93 look like SATA. If they are on the blacklist then we must not test for SATA but assume 40 wire in the 40 wire case (The TSSCorp reports 80 wire on SATA it seems!) Signed-off-by: Alan Cox <alan@redhat.com> Cc: Tejun Heo <htejun@gmail.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
| * [libata] core checkpatch fixAndrew Morton2008-01-15
| | | | | | | | | | | | | | | | Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Jeff Garzik <jeff@garzik.org> Cc: Tejun Heo <htejun@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
| * [libata] pata_bf54x: checkpatch fixesAndrew Morton2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WARNING: line over 80 characters #36: FILE: drivers/ata/pata_bf54x.c:1512: + while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) { ERROR: need spaces around that '>' (ctx:VxV) #36: FILE: drivers/ata/pata_bf54x.c:1512: + while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) { ^ total: 1 errors, 1 warnings, 19 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jeff Garzik <jeff@garzik.org> Cc: Sonic Zhang <sonic.zhang@analog.com> Cc: Tejun Heo <htejun@gmail.com> Cc: sonic zhang <sonic.adi@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
| * libata fixes for sparse-found problemsAl Viro2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In pata_legacy and pata_winbond we've got bugs - cpu_to_le16() instead of cpu_to_le32(). Fortunately, both affected suckers are VLB, thus l-e-only, so we might get away with that unless we hit it with slop == 3 (hadn't checked if playing with badly aligned sg could trigger that). Still buggy... Moreover, pata_legacy, pata_winbond and pata_qdi forgot to initialize pad on the write side of 32bit case in their ->data_xfer(). Hopefully the hardware does't care, but still, sending uninitialized data to it... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* | Fix Blackfin HARDWARE_PM supportMathieu Desnoyers2008-01-15
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch restores the blackfin Hardware Performance Monitor Profiling support that was killed by the combining of instrumentation menus in commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9. Since there seems to be no good reason to behave differently from other architectures, it now automatically selects the hardware performance counters whenever the profiling is activated. mach-common/irqpanic.c: pm_overflow calls pm_overflow_handler which is in oprofile/op_model_bf533.c. I doubt that setting HARDWARE_PM as "m" will work at all, since the pm_overflow_handler should be in the core kernel image because it is called by irqpanic.c. Therefore, I change HARDWARE_PM from a tristate to a bool. The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since part of the HARDWARE_PM support files sits in this directory, it makes sense to also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on PROFILING, it is correct to only depend on OPROFILE only. Thanks to Adrian Bunk for finding this bug and providing an initial patch. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Adrian Bunk <adrian.bunk@movial.fi> CC: Randy Dunlap <randy.dunlap@oracle.com> CC: bryan.wu@analog.com Acked-by: Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Fix ARM profiling/instrumentation configurationLinus Torvalds2008-01-15
| | | | | | | | | | | | | | | | | | | Commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 ("Combine instrumentation menus in kernel/Kconfig.instrumentation") broke ARM profiling support, since ARM has some extra Kconfig options and doesn't just use the common OPROFILE/KPROBES config options. Rather than just revert the thing outright, or add ARM-specific knowledge to the generic Kconfig.instrumentation file (where the only and whole point was to be generic, not too architecture-specific), this just makes ARM not use the generic version, since it doesn't suit it. So create an arm-specific version of Kconfig.instrumentation instead, and use that. Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Russell King <rmk+lkml@arm.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86Linus Torvalds2008-01-15
|\ | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86: fix RTC_AIE with CONFIG_HPET_EMULATE_RTC x86: asm-x86/msr.h: pull in linux/types.h x86: fix boot crash on HIGHMEM4G && SPARSEMEM
| * x86: fix RTC_AIE with CONFIG_HPET_EMULATE_RTCBernhard Walle2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the current code, RTC_AIE doesn't work if the RTC relies on CONFIG_HPET_EMULATE_RTC because the code sets the RTC_AIE flag in hpet_set_rtc_irq_bit(). The interrupt handles does accidentally check for RTC_PIE and not RTC_AIE when comparing the time which was set in hpet_set_alarm_time(). I now verified on a test system here that without the patch applied, the attached test program fails on a system that has HPET with 2.6.24-rc7-default. That's not critical since I guess the problem has been there for several kernel releases, but as the fix is quite obvious. Configuration is CONFIG_RTC=y and CONFIG_HPET_EMULATE_RTC=y. Signed-off-by: Bernhard Walle <bwalle@suse.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * x86: asm-x86/msr.h: pull in linux/types.hMike Frysinger2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | Since the msr.h header uses types like __u32, it should pull in linux/types.h. [ mingo@elte.hu: affects user-space that includes this header. We dont actually like user-space including raw kernel headers but it's a longstanding practice and it's easy for the kernel to be nice about this. ] Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * x86: fix boot crash on HIGHMEM4G && SPARSEMEMIngo Molnar2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Denys Fedoryshchenko reported a bootup crash when he upgraded his system from 3GB to 4GB RAM: http://lkml.org/lkml/2008/1/7/9 the bug is due to HIGHMEM4G && SPARSEMEM kernels making pfn_to_page() to return an invalid pointer when the pfn is in a memory hole. The 256 MB PCI aperture at the end of RAM was not mapped by sparsemem, and hence the pfn was not valid. But set_highmem_pages_init() iterated this range without checking the pfn's validity first. this bug was probably present in the sparsemem code ever since sparsemem has been introduced in v2.6.13. It was masked due to HIGHMEM64G using larger memory regions in sparsemem_32.h: #ifdef CONFIG_X86_PAE #define SECTION_SIZE_BITS 30 #define MAX_PHYSADDR_BITS 36 #define MAX_PHYSMEM_BITS 36 #else #define SECTION_SIZE_BITS 26 #define MAX_PHYSADDR_BITS 32 #define MAX_PHYSMEM_BITS 32 #endif which creates 1GB sparsemem regions instead of 64MB sparsemem regions. So in practice we only ever created true sparsemem holes on x86 with HIGHMEM4G - but that was rarely used by distros. ( btw., we could probably save 2MB of mem_map[]s on X86_PAE if we reduced the sparsemem region size to 256 MB. ) Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Thomas Gleixner <tglx@linutronix.de>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6Linus Torvalds2008-01-15
|\ \ | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC64]: Fix build with SPARSEMEM_VMEMMAP disabled. [SPARC]: Make gettimeofday() monotonic again.
| * | [SPARC64]: Fix build with SPARSEMEM_VMEMMAP disabled.David S. Miller2008-01-13
| | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | [SPARC]: Make gettimeofday() monotonic again.David S. Miller2008-01-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we switched away from the optimized C version things stopped being monotonic. The problem is that if we run this with interrupts disabled, we can see the interrupt pending because the counter reached the limit value. When this happens the counter has bit 31 set, and the low bits start counting again from zero. Reported by Martin Habets. Signed-off-by: David S. Miller <davem@davemloft.net>
* | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds2008-01-15
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: [TOKENRING]: rif_timer not initialized properly [NETFILTER]: bridge: fix double POST_ROUTING invocation [NETFILTER]: xt_helper: Do not bypass RCU [NETFILTER]: ip6t_eui64: Fixes calculation of Universal/Local bit [MACVLAN]: Prevent nesting macvlan devices [VLAN]: nested VLAN: fix lockdep's recursive locking warning [DECNET] ROUTE: fix rcu_dereference() uses in /proc/net/decnet_cache [BLUETOOTH]: Always send explicit hci_ll wake-up acks. [BLUETOOTH]: rfcomm tty BUG_ON() code fix [AX25] af_ax25: Possible circular locking. [AX25]: Kill user triggable printks. [IPV4] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache [NEIGH]: Fix race between neigh_parms_release and neightbl_fill_parms [NIU]: Support for Marvell PHY
| * | | [TOKENRING]: rif_timer not initialized properlyEric Dumazet2008-01-14
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [NETFILTER]: bridge: fix double POST_ROUTING invocationPatrick McHardy2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bridge code incorrectly causes two POST_ROUTING hook invocations for DNATed packets that end up on the same bridge device. This happens because packets with a changed destination address are passed to dst_output() to make them go through the neighbour output function again to build a new destination MAC address, before they will continue through the IP hooks simulated by bridge netfilter. The resulting hook order is: PREROUTING (bridge netfilter) POSTROUTING (dst_output -> ip_output) FORWARD (bridge netfilter) POSTROUTING (bridge netfilter) The deferred hooks used to abort the first POST_ROUTING invocation, but since the only thing bridge netfilter actually really wants is a new MAC address, we can avoid going through the IP stack completely by simply calling the neighbour output function directly. Tested, reported and lots of data provided by: Damien Thebault <damien.thebault@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [NETFILTER]: xt_helper: Do not bypass RCUJan Engelhardt2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the @helper variable that was just obtained. Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [NETFILTER]: ip6t_eui64: Fixes calculation of Universal/Local bitYasuyuki Kozakai2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC2464 says that the next to lowerst order bit of the first octet of the Interface Identifier is formed by complementing the Universal/Local bit of the EUI-64. But ip6t_eui64 uses OR not XOR. Thanks Peter Ivancik for reporing this bug and posting a patch for it. Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [MACVLAN]: Prevent nesting macvlan devicesPatrick McHardy2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't allow to nest macvlan devices since it will cause lockdep warnings and isn't really useful for anything. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [VLAN]: nested VLAN: fix lockdep's recursive locking warningJarek Poplawski2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow vlans nesting other vlans without lockdep's warnings (max. 2 levels i.e. parent + child). Thanks to Patrick McHardy for pointing a bug in the first version of this patch. Reported-by: Benny Amorsen Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [DECNET] ROUTE: fix rcu_dereference() uses in /proc/net/decnet_cacheEric Dumazet2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In dn_rt_cache_get_next(), no need to guard seq->private by a rcu_dereference() since seq is private to the thread running this function. Reading seq.private once (as guaranted bu rcu_dereference()) or several time if compiler really is dumb enough wont change the result. But we miss real spots where rcu_dereference() are needed, both in dn_rt_cache_get_first() and dn_rt_cache_get_next() Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [BLUETOOTH]: Always send explicit hci_ll wake-up acks.Ohad Ben-Cohen2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the (rare) event of simultaneous mutual wake up requests, do send the chip an explicit wake-up ack. This is required for Texas Instruments's BRF6350 chip. Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [BLUETOOTH]: rfcomm tty BUG_ON() code fixDave Young2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) In tty.c the BUG_ON at line 115 will never be called, because the the before list_del_init in this same function. 115 BUG_ON(!list_empty(&dev->list)); So move the list_del_init to rfcomm_dev_del 2) The rfcomm_dev_del could be called from diffrent path (rfcomm_tty_hangup/rfcomm_dev_state_change/rfcomm_release_dev), So add another BUG_ON when the rfcomm_dev_del is called more than one time. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [AX25] af_ax25: Possible circular locking.Jarek Poplawski2008-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bernard Pidoux F6BVP reported: > When I killall kissattach I can see the following message. > > This happens on kernel 2.6.24-rc5 already patched with the 6 previously > patches I sent recently. > > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.23.9 #1 > ------------------------------------------------------- > kissattach/2906 is trying to acquire lock: > (linkfail_lock){-+..}, at: [<d8bd4603>] ax25_link_failed+0x11/0x39 [ax25] > > but task is already holding lock: > (ax25_list_lock){-+..}, at: [<d8bd7c7c>] ax25_device_event+0x38/0x84 > [ax25] > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: ... lockdep is worried about the different order here: #1 (rose_neigh_list_lock){-+..}: #3 (ax25_list_lock){-+..}: #0 (linkfail_lock){-+..}: #1 (rose_neigh_list_lock){-+..}: #3 (ax25_list_lock){-+..}: #0 (linkfail_lock){-+..}: So, ax25_list_lock could be taken before and after linkfail_lock. I don't know if this three-thread clutch is very probable (or possible at all), but it seems another bug reported by Bernard ("[...] system impossible to reboot with linux-2.6.24-rc5") could have similar source - namely ax25_list_lock held by ax25_kill_by_device() during ax25_disconnect(). It looks like the only place which calls ax25_disconnect() this way, so I guess, it isn't necessary. This patch is breaking the lock for ax25_disconnect(). Reported-and-tested-by: Bernard Pidoux <f6bvp@free.fr> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [AX25]: Kill user triggable printks.maximilian attems2008-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sfuzz can easily trigger any of those. move the printk message to the corresponding comment: makes the intention of the code clear and easy to pick up on an scheduled removal. as bonus simplify the braces placement. Signed-off-by: maximilian attems <max@stro.at> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [IPV4] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cacheEric Dumazet2008-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In rt_cache_get_next(), no need to guard seq->private by a rcu_dereference() since seq is private to the thread running this function. Reading seq.private once (as guaranted bu rcu_dereference()) or several time if compiler really is dumb enough wont change the result. But we miss real spots where rcu_dereference() are needed, both in rt_cache_get_first() and rt_cache_get_next() Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [NEIGH]: Fix race between neigh_parms_release and neightbl_fill_parmsPavel Emelyanov2008-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The neightbl_fill_parms() is called under the write-locked tbl->lock and accesses the parms->dev. The negh_parm_release() calls the dev_put(parms->dev) without this lock. This creates a tiny race window on which the parms contains potentially stale dev pointer. To fix this race it's enough to move the dev_put() upper under the tbl->lock, but note, that the parms are held by neighbors and thus can live after the neigh_parms_release() is called, so we still can have a parm with bad dev pointer. I didn't find where the neigh->parms->dev is accessed, but still think that putting the dev is to be done in a place, where the parms are really freed. Am I right with that? Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | [NIU]: Support for Marvell PHYMirko Lindner2008-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From: Mirko Lindner <mlindner@marvell.com> This patch makes necessary changes in the Neptune driver to support the new Marvell PHY. It also adds support for the LED blinking on Neptune cards with Marvell PHY. All registers are using defines in the niu.h header file as is already done for the BCM8704 registers. [ Coding style, etc. cleanups -DaveM ] Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | Merge branch 'merge' of ↵Linus Torvalds2008-01-15
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc: [POWERPC] Fix boot failure on POWER6 [POWERPC] Workaround for iommu page alignment
| * | | [POWERPC] Fix boot failure on POWER6Paul Mackerras2008-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 473980a99316c0e788bca50996375a2815124ce1 added a call to clear the SLB shadow buffer before registering it. Unfortunately this means that we clear out the entries that slb_initialize has previously set in there. On POWER6, the hypervisor uses the SLB shadow buffer when doing partition switches, and that means that after the next partition switch, each non-boot CPU has no SLB entries to map the kernel text and data, which causes it to crash. This fixes it by reverting most of 473980a9 and instead clearing the 3rd entry explicitly in slb_initialize. This fixes the problem that 473980a9 was trying to solve, but without breaking POWER6. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * | | [POWERPC] Workaround for iommu page alignmentBenjamin Herrenschmidt2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 5d2efba64b231a1733c4048d1708d77e07f26426 changed our iommu code so that it always uses an iommu page size of 4kB. That means with our current code, drivers may do a dma_map_sg() of a 64kB page and obtain a dma_addr_t that is only 4k aligned. This works fine in most cases except for some infiniband HW it seems, where they tell the HW about the page size and it ignores the low bits of the DMA address. This works around it by making our IOMMU code enforce a PAGE_SIZE alignment for mappings of objects that are page aligned in the first place and whose size is larger or equal to a page. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* | | | Merge branch 'upstream-linus' of ↵Linus Torvalds2008-01-15
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata: relocate sdev->manage_start_stop configuration sata_sil24: freeze on non-dev errors reported via CERR sata_sil24: fix stupid typo ata_piix: ignore ATA_DMA_ERR on vmware ich4
| * | | | libata: relocate sdev->manage_start_stop configurationTejun Heo2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After 9b8e8de7, manage_start_stop configuration depends on valid ATA device. Move it into ata_scsi_dev_config(). This was detected by the coverity checker. Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Adrian Bunk <bunk@kernel.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
| * | | | sata_sil24: freeze on non-dev errors reported via CERRTejun Heo2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CERR reports errors detected during executing a command. This doesn't mean the error is tied to the command and can be recovered by just issuing it again. Many of the errors are fatal port-wide connditions including HSM violation, host bus error and ATA bus error and require freezing and port reset. The freezing part wasn't implemented previously. This used to be okay because port resets were scheduled anyway and EH eventually resets and recovers the port. With PMP support added, this is no longer true. The error condition and recover actions are attributed to the fan-out port and the host port condition isn't properly recovered leading to EH failures. This patch makes CERR errors which require resets to freeze the port. This will force host port reset and proper recovery. Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Andrew Ryder <tireman@shaw.ca> Signed-off-by: Jeff Garzik <jeff@garzik.org>
| * | | | sata_sil24: fix stupid typoTejun Heo2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix stupid typo. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
| * | | | ata_piix: ignore ATA_DMA_ERR on vmware ich4Tejun Heo2008-01-14
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | VMware ich4 emulation incorrectly sets DMA_ERR on TF error. Ignore it. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* | | | Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds2008-01-15
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Cacheops.h: Fix typo. [MIPS] Cobalt: Qube1 has no serial port so don't use it [MIPS] Cobalt: Fix ethernet interrupts for RaQ1 [MIPS] Kconfig fixes for BCM47XX platform
| * | | | [MIPS] Cacheops.h: Fix typo.Ralf Baechle2008-01-14
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | [MIPS] Cobalt: Qube1 has no serial port so don't use itThomas Bogendoerfer2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because Qube1 doesn't have a serial chip waiting for transmit fifo empty takes forever, which isn't a good idea. No prom_putchar/early console for Qube1 fixes this. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | [MIPS] Cobalt: Fix ethernet interrupts for RaQ1Thomas Bogendoerfer2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RAQ1 uses the same interrupt routing as Qube2. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
| * | | | [MIPS] Kconfig fixes for BCM47XX platformAurelien Jarno2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch below fixes two problems for Kconfig on the BCM47xx platform: - arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. Selecting SSB_DRIVER_EXTIF makes sure those functions are available. - arch/mips/pci/pci.c needs, when enabled, platform specific functions, which are defined when SSB_PCICORE_HOSTMODE is enabled. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
* | | | | Revert "writeback: introduce writeback_control.more_io to indicate more io"Linus Torvalds2008-01-15
| |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2e6883bdf49abd0e7f0d9b6297fc3be7ebb2250b, as requested by Fengguang Wu. It's not quite fully baked yet, and while there are patches around to fix the problems it caused, they should get more testing. Says Fengguang: "I'll resend them both for -mm later on, in a more complete patchset". See http://bugzilla.kernel.org/show_bug.cgi?id=9738 for some of this discussion. Requested-by: Fengguang Wu <wfg@mail.ustc.edu.cn> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | Merge branch 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6Linus Torvalds2008-01-14
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: i2c-sibyte: Fix an error path i2c: Driver IDs are optional i2c: Spelling fixes i2c-omap: Fix NULL pointer dereferencing
| * | | | i2c-sibyte: Fix an error pathJean Delvare2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the registration of the second I2C channel fails, we really want to unregister the first one before we return with an error. While we're here, fix the printk right above so that it displays the real driver name. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Ralf Baechle <ralf@linux-mips.org>
| * | | | i2c: Driver IDs are optionalJean Delvare2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Document the fact that I2C driver IDs are optional. Signed-off-by: Jean Delvare <khali@linux-fr.org>
| * | | | i2c: Spelling fixesJoe Perches2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [JD: One more fix in i2c-dev.] Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
| * | | | i2c-omap: Fix NULL pointer dereferencingTony Lindgren2008-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes bug #9581 reported by Marcio Buss. If kzalloc fails, omap_i2c_write_reg() tries to reset an unallocated I2C controller. Cc: Marcio Buss <marciobuss@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-22 13:32:03 -0500