- 20 Aug, 2008 40 commits
-
-
David Miller authored
Commit efc49181 upstream radeon: misc corrections I have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that hangs in my sparc64 boxes when the init scripts set the font. The problem goes away if I disable acceleration. I haven't figured out that bug yet, but along the way I found some corrections to make based upon some auditing. 1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver and the XORG video driver differ. I've made the kernel match what XORG is using. 2) In radeonfb_engine_reset() we have top-level code structure that roughly looks like: if (family is 300, 350, or V350) do this; else do that; ... if (family is NOT 300, OR family is NOT 350, OR family is NOT V350) do another thing; this last conditional makes no sense, is always true, and obviously was likely meant to be "family is NOT 300, 350, or V350". So I've made the code match the intent. Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jan Beulich authored
commit 04e1e0cc upstream. Signed-off-by:
Steve French <sfrench@us.ibm.com> Cc: Eugene Teo <eteo@redhat.com> Signed-off-by:
-
Dimitri Gorokhovik authored
commit 84e0f3f6 upstream The driver of ITE8212 in pass-through mode (it8212.noraid=1 on cmndline) attempts to use the field `.dma_host_set' of the struct ide_dma_ops in `ide_config_drive_speed' which is set to NULL by default. So give a value to all fields of the struct ide_dma_ops. Signed-off-by:
Dimitri Gorokhovik <dimitri.gorokhovik@free.fr> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Yinghai Lu authored
commit 8004dd96 upstream. there is a typo in the mask value, need to remove that extra 0, to avoid 4bit clearing. Signed-off-by:
Yinghal Lu <yhlu.kernel@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: maximilian attems <max@stro.at> Cc: Peter Palfrader <weasel@debian.org> Cc: dann frazier <dannf@debian.org> Signed-off-by:
-
Timur Tabi authored
Upstream-commit-id: bf9c8c9d If an OSS application calls SNDCTL_DSP_SYNC, then ALSA will call the driver's _hw_params and _prepare functions again. On the Freescale MPC8610 DMA ASoC driver, this caused the DMA controller to be unneccessarily re-programmed, and apparently it doesn't like that. The DMA will then not operate when instructed. This patch relocates much of the DMA programming to fsl_dma_open(), which is called only once. Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jean Delvare authored
Already in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d24f8dcb7ead491704e274883b2c627062f6235 In kernel 2.6.26, the ability to select I2C algorithm drivers manually was removed, as all in-kernel drivers do that automatically. However there were some complaints that it was a problem for out-of-tree I2C bus drivers. In order to address these complaints, let's allow manual selection of these drivers again, but still hide them by default for better general user experience. This closes bug #11140: http://bugzilla.kernel.org/show_bug.cgi?id=11140Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Hans Verkuil authored
Already in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b25b791b13aaa336b56c4f9bd417ff126363f80b Fix a NULL pointer dereference that happened when calling i2c_new_probed_device on one of the addresses for which we use byte reads instead of quick write for detection purpose (that is: 0x30-0x37 and 0x50-0x5f). Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Timur Tabi authored
Upstream-commid-id: be41e941 The Freescale MPC8610 SSI device has the option of using one clock for both transmit and receive (synchronous mode), or independent clocks (asynchronous). The SSI driver, however, programs the SSI into synchronous mode and then tries to program the clock registers independently. The result is that the wrong sample size is usually generated during recording. This patch fixes the discrepancy by restricting the sample rate and sample size of the playback and capture streams. The SSI driver remembers which stream is opened first. When a second stream is opened, that stream is constrained to the same sample rate and size as the first stream. A future version of this driver will lift the sample size restriction. Supporting independent sample rates is more difficult, because only certain codecs provide dual independent clocks. Signed-off-by:
-
Marcus Sundberg authored
commit 77332894 upstream The magic write to register 0x82 will often cause PCI config space on my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop) to be filled with ones during driver load, and thus breaking NIC operation until reboot. If it does not happen on first driver load it can easily be reproduced by unloading and loading the driver a few times. The magic write was added long ago by this commit: Author: François Romieu <romieu@fr.zoreil.com> Date: Sat Jan 10 06:00:46 2004 -0500 [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one(): - phy capability settings allows lower or equal capability as suggested in Realtek's changes; - I/O voodoo; - no need to s/mdio_write/RTL8169_WRITE_GMII_REG/; - s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/; - rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication of code (yep, the u16 -> int conversions should work as expected); - variable renames and whitepace changes ignored. As the 8168 wasn't supported by that version this patch simply removes the bogus write from mac versions <= RTL_GIGA_MAC_VER_06. [The change above makes sense for the 8101/8102 too -- Ueimor] Signed-off-by:
Marcus Sundberg <marcus@ingate.com> Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Cc: Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Julia Lawall authored
(cherry picked from commit cab7a1ee) There is a call to local_irq_restore in the normal exit case, so it would seem that there should be one on an error return as well. The semantic patch that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression l; expression E,E1,E2; @@ local_irq_save(l); ... when != local_irq_restore(l) when != spin_unlock_irqrestore(E,l) when any when strict ( if (...) { ... when != local_irq_restore(l) when != spin_unlock_irqrestore(E1,l) + local_irq_restore(l); return ...; } | if (...) + {local_irq_restore(l); return ...; + } | spin_unlock_irqrestore(E2,l); | local_irq_restore(l); ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit c93cd3a5) If 'g' is one then limit is 4kb granular. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Avi Kivity authored
(cherry-picked from commit 577bdc49) When an event (such as an interrupt) is injected, and the stack is shadowed (and therefore write protected), the guest will exit. The current code will see that the stack is shadowed and emulate a few instructions, each time postponing the injection. Eventually the injection may succeed, but at that time the guest may be unwilling to accept the interrupt (for example, the TPR may have changed). This occurs every once in a while during a Windows 2008 boot. Fix by unshadowing the fault address if the fault was due to an event injection. Signed-off-by:
-
Marcelo Tosatti authored
(cherry-picked from commit 34198bf8) There is no guarantee that the old TSS descriptor in the GDT contains the proper base address. This is the case for Windows installation's reboot-via-triplefault. Use guest registers instead. Also translate the address properly. Signed-off-by:
-
Marcelo Tosatti authored
(cherry picked from commit 98899aa0) The segment base is always a linear address, so translate before accessing guest memory. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 0a4949c4 ] That's the userland thread register, so we should never try to change it like this. Based upon glibc bug nptl/6577 and suggestions by Jakub Jelinek. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 17b6f586 ] We were picking %i7 out of the wrong register window stack slot. Signed-off-by:
-
Mikael Pettersson authored
[ Upstream commit d72609e1 ] Correct sparc64's implementation of FUTEX_OP_ANDN to do a bitwise negate of the oparg parameter before applying the AND operation. All other archs that support FUTEX_OP_ANDN either negate oparg explicitly (frv, ia64, mips, sh, x86), or do so indirectly by using an and-not instruction (powerpc). Since sparc64 has and-not, I chose to use that solution. I've not found any use of FUTEX_OP_ANDN in glibc so the impact of this bug is probably minor. But other user-space components may try to use it so it should still get fixed. Signed-off-by:
Mikael Pettersson <mikpe@it.uu.se> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit 77e2f14f ] SCTP used ip6_xmit() to send fragments after received ICMP packet too big message. But while send packet used ip6_xmit, the skb->local_df is not initialized. So when skb if enter ip6_fragment(), the following code will discard the skb. ip6_fragment(...) { if (!skb->local_df) { ... return -EMSGSIZE; } ... } SCTP do the following step: 1. send packet ip6_xmit(skb, ipfragok=0) 2. received ICMP packet too big message 3. if PMTUD_ENABLE: ip6_xmit(skb, ipfragok=1) This patch fixed the problem by set local_df if ipfragok is true. Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit 697f8d03 ] The rationale is: * use u32 consistently * no need to do LCG on values from (better) get_random_bytes * use more data from get_random_bytes for secondary seeding * don't reduce state space on srandom32() * enforce state variable initialization restrictions Note: the second paper has a version of random32() with even longer period and a version of random64() if needed. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit 16df845f ] ecn_ok is not initialized when a connection is established by cookies. The cookie syn-ack never sets ECN, so ecn_ok must be set to 0. Spotted using ns-3/network simulation cradle simulator and valgrind. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit 3e8a0a55 upstream Thanks to Eugene Teo for reporting this problem. Signed-off-by:
Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Steve French authored
commit 2c731afb upstream Signed-off-by:
-
Steve French authored
commit ad661334 upstream In looking at network named pipe support on cifs, I noticed that Dave Howell's iget patch: iget: stop CIFS from using iget() and read_inode() broke mounts to IPC$ (the interprocess communication share), and don't handle the error case (when getting info on the root inode fails). Thanks to Gunter who noted a typo in a debug line in the original version of this patch. CC: David Howells <dhowells@redhat.com> CC: Gunter Kukkukk <linux@kukkukk.com> Signed-off-by:
-
Carlos Corbacho authored
commit 5c742b45 upstream In the old acer_acpi, I discovered that on some of the newer AMW0 laptops that supported the WMID methods, they don't work properly for setting the wireless and bluetooth values. So for the AMW0 V2 laptops, we want to use both the 'old' AMW0 and the 'new' WMID methods for setting wireless & bluetooth to guarantee we always enable it. This was fixed in acer_acpi some time ago, but I forgot to port the patch over to acer-wmi when it was merged. (Without this patch, early AMW0 V2 laptops such as the Aspire 5040 won't work with acer-wmi, where-as they did with the old acer_acpi). AK: fix compilation Signed-off-by:
Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Sven Wegener authored
commit 8ab19ea3 upstream There is a slight chance for a deadlock in the estimator code. We can't call del_timer_sync() while holding our lock, as the timer might be active and spinning for the lock on another cpu. Work around this issue by using try_to_del_timer_sync() and releasing the lock. We could actually delete the timer outside of our lock, as the add and kill functions are only every called from userspace via [gs]etsockopt() and are serialized by a mutex, but better make this explicit. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Andre Schenk authored
commit b5894a50 upstream USB product id registration for the ELV HS485 USB adapter (www.elv.de) to their home automation bus system. Applies to 2.6.26. Signed-off-by:
Andre Schenk <andre@melior.s.bawue.de> Signed-off-by:
-
Frederik Kriewitz authored
commit a00c3cad upstream The Patch adds support for Luminance Stellaris Evaluation/Development Kits (FTDI 2232C based). The PIDs were missing. Successfully tested with a Stellaris LM3S8962 Evaluation kit. Signed-off-by:
Frederik Kriewitz <frederik@kriewitz.eu> Signed-off-by:
-
Alan Stern authored
commit 0282b7f2 upstream This patch (as1121) fixes a bug in the USB serial core. When a device is unregistered, the core will give back its minors -- even if the device hasn't been assigned any! The patch reserves the highest minor value (255) to mean that no minor was assigned. It also removes some dead code and does a small style fixup. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Dave Jones authored
commit b9a097f2 upstream usb-storage: quirk around v1.11 firmware on Nikon D40 https://bugzilla.redhat.com/show_bug.cgi?id=454028 Just as in earlier firmware versions, we need to perform this quirk for the latest version too. Speculatively do the entry for the D80 too, as they seem to have the same firmware problems historically. Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 368ee646 upstream This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card reader. Apparently these devices provide reasonable residue values for READ and WRITE operations, but not for others like INQUIRY or READ CAPACITY. This fixes the iRiver T10 problem reported in Bugzilla #11125. Signed-off-by:
-
Alan Stern authored
commit 1a21175a upstream This patch (as1122) fixes a bug: When an interface is unregistered, its children (sysfs files and endpoint devices) are unregistered after it instead of before. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
-
Tollef Fog Heen authored
commit 8c809681 upstream USB ID 4348:5523 is handled by the ch341 driver. Remove it from the pl2023 driver. Reverts 002e8f2c. Signed-off-by:
Tollef Fog Heen <tfheen@err.no> Signed-off-by:
-
Jean Delvare authored
commit 5ede40f8 upstream I broke an error path with d03c21ec, sorry about that. The machine will crash if the i2c_attach_client() or maven_init_client() calls fail, although nobody has yet reported this happening. Signed-off-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz> Signed-off-by:
-
David Miller authored
commit 969830b2 upstream Some chips appear to have the 2D engine hang during screen redraw, typically in a sequence of copyarea operations. This appear to be solved by adding a flush of the engine destination pixel cache and waiting for the engine to be idle before issuing the accel operation. The performance impact seems to be fairly small. Here is a trace on an RV370 (PCI device ID 0x5b64), it records the RBBM_STATUS register, then the source x/y, destination x/y, and width/height used for the copy: ---------------------------------------- radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10] radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10] radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10] radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10] radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10] radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10] radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10] radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10] radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10] radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10] radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10] ---------------------------------------- When things are going fine the copies complete before the next ROP is even issued, but all of a sudden the 2D unit becomes active (bit 17 in RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit 14) are set as well. The FIFO begins to backup until it becomes full. What happens next is the radeon_fifo_wait() times out, and we access the chip illegally leading to a bus error which usually wedges the box. None of this makes it to the console screen, of course :-) radeon_fifo_wait() should be modified to reset the accelerator when this timeout happens instead of programming the chip anyways. ---------------------------------------- radeonfb: FIFO Timeout ! ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0) ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601] ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248> ERROR(0): M_SYND(0), E_SYND(0), Privileged ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus" ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000] ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\ ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000] ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000] ERROR(0): E-cache idx[800e40] tag[000000000e049f4c] ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000] Ker:xnel panic - not syncing: Irrecoverable deferred error trap. ---------------------------------------- Another quirk is that these copyarea calls will not happen until the first drivers/char/vt.c:redraw_screen() occurs. This will only happen if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen. This seems to happen because until a redraw_screen() the screen scrolling method used by fbcon is not finalized yet. I've seen this with other fb drivers too. So if all you do is boot straight into X you will never see this bug on the relevant chips. Signed-off-by:
-
Oleg Nesterov authored
commit ba661292 upstream The bug was reported and analysed by Mark McLoughlin <markmc@redhat.com>, the patch is based on his and Roland's suggestions. posix_timer_event() always rewrites the pre-allocated siginfo before sending the signal. Most of the written info is the same all the time, but memset(0) is very wrong. If ->sigq is queued we can race with collect_signal() which can fail to find this siginfo looking at .si_signo, or copy_siginfo() can copy the wrong .si_code/si_tid/etc. In short, sys_timer_settime() can in fact stop the active timer, or the user can receive the siginfo with the wrong .si_xxx values. Move "memset(->info, 0)" from posix_timer_event() to alloc_posix_timer(), change send_sigqueue() to set .si_overrun = 0 when ->sigq is not queued. It would be nice to move the whole sigq->info initialization from send to create path, but this is not easy to do without uglifying timer_create() further. As Roland rightly pointed out, we need more cleanups/fixes here, see the "FIXME" comment in the patch. Hopefully this patch makes sense anyway, and it can mask the most bad implications. Reported-by:
Mark McLoughlin <markmc@redhat.com> Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Mark McLoughlin <markmc@redhat.com> Cc: Oliver Pinter <oliver.pntr@gmail.com> Cc: Roland McGrath <roland@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Oleg Nesterov authored
commit 54da1174 upstream do_schedule_next_timer() sets info->si_overrun = timr->it_overrun_last, this discards the already accumulated overruns. Signed-off-by:
-
Petr Tesarik authored
commit 938bb03d uptream Aesthetic regards aside, commit e8e7b9eb still leaves a bug in the error message, because it uses the unconverted big-endian value for printk. Fix this by using a local variable in machine byte order. The result is correct, more readable, and also produces slightly shorter code on i386. Signed-off-by:
Petr Tesarik <ptesarik@suse.cz> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Jan Kara <jack@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@kernel.org> Acked-by:
Borislav Petkov <petkovbb@gmail.com> [bart: __u32 -> u32] Signed-off-by:
-
Tom Zanussi authored
commit 32194450 upstream In relay's current read implementation, if the buffer is completely full but hasn't triggered the buffer-full condition (i.e. the last write didn't cross the subbuffer boundary) and the last subbuffer is exactly full, the subbuffer accounting code erroneously finds nothing available. This patch fixes the problem. Signed-off-by:
Tom Zanussi <tzanussi@gmail.com> Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org> Cc: Andrea Righi <righi.andrea@gmail.com> Signed-off-by:
-
Ondrej Zajicek authored
commit 594a8819 upstream commit 20e061fb Author: Ondrej Zajicek <santiago@crfreenet.org> Date: Mon Apr 28 02:15:18 2008 -0700 fbdev: framebuffer_alloc() fixes Correct the dev arg of framebuffer_alloc() in arkfb, s3fb and vt8623fb. causes a null-pointer deref because "info->dev is NULL, info was just kzallocated". Signed-off-by:
Ondrej Zajicek <santiago@crfreenet.org> Reported-by:
"MadLoisae@gmx.net" <MadLoisae@gmx.net> Tested-by:
-
HighPoint Linux Team authored
commit dd07428b upstream Add PCI device ID for new adapter models. Signed-off-by:
HighPoint Linux Team <linux@highpoint-tech.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
