- 08 Sep, 2008 8 commits
-
-
Samuel Sieb authored
commit c6744955 upstream Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped booting starting at v2.6.22. The reason is this commit: > commit f25f64ed > Author: Juergen Beisert <juergen@kreuzholzen.de> > Date: Sun Jul 22 11:12:38 2007 +0200 > > x86: Replace NSC/Cyrix specific chipset access macros by inlined functions. this commit activated a macro which was dormant before due to (buggy) macro side-effects. I've looked through various datasheets and found that the GXm and GXLV Geode processors don't have an incrementor. Remove the incrementor setup entirely. As the incrementor value differs according to clock speed and we would hope that the BIOS configures it correctly, it is probably the right solution. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Yinghai Lu authored
commit 38cc1c3d upstream Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is usable. Booting with mtrr_show showed us the BIOS-initialized MTRR settings - which are all wrong. So the root cause is that the BIOS has not set the mask correctly: > [ 0.429971] MSR00000200: 00000000d0000000 > [ 0.433305] MSR00000201: 0000000ff0000800 > should be ==> [ 0.433305] MSR00000201: 0000003ff0000800 > > [ 0.436638] MSR00000202: 00000000e0000000 > [ 0.439971] MSR00000203: 0000000fe0000800 > should be ==> [ 0.439971] MSR00000203: 0000003fe0000800 > > [ 0.443304] MSR00000204: 0000000000000006 > [ 0.446637] MSR00000205: 0000000c00000800 > should be ==> [ 0.446637] MSR00000205: 0000003c00000800 > > [ 0.449970] MSR00000206: 0000000400000006 > [ 0.453303] MSR00000207: 0000000fe0000800 > should be ==> [ 0.453303] MSR00000207: 0000003fe0000800 > > [ 0.456636] MSR00000208: 0000000420000006 > [ 0.459970] MSR00000209: 0000000ff0000800 > should be ==> [ 0.459970] MSR00000209: 0000003ff0000800 So detect this borkage and add the prefix 111. Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
commit 74573ee7 upstream On Wed, Jul 23, 2008 at 03:52:36PM +0300, Andrei Popa wrote: > I installed gnokii-0.6.22-r2 and gave the command "gnokii --identify" > and the kernel oopsed: > > BUG: unable to handle kernel NULL pointer dereference at 00000458 > IP: [<c0444b52>] mutex_unlock+0x0/0xb > [<c03830ae>] acm_tty_open+0x4c/0x214 Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Tested-by:
Andrei Popa <andrei.popa@i-neo.ro> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Pavel Emelyanov authored
commit ff9bc512 upstream Date: Wed, 20 Aug 2008 14:09:10 -0700 Subject: binfmt_misc: fix false -ENOEXEC when coupled with other binary handlers In case the binfmt_misc binary handler is registered *before* the e.g. script one (when for example being compiled as a module) the following situation may occur: 1. user launches a script, whose interpreter is a misc binary; 2. the load_misc_binary sets the misc_bang and returns -ENOEVEC, since the binary is a script; 3. the load_script_binary loads one and calls for search_binary_hander to run the interpreter; 4. the load_misc_binary is called again, but refuses to load the binary due to misc_bang bit set. The fix is to move the misc_bang setting lower - prior to the actual call to the search_binary_handler. Caused by the commit 3a2e7f47 (binfmt_misc.c: avoid potential kernel stack overflow) Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Reported-by:
Kirill A. Shutemov <kirill@shutemov.name> Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Ian Campbell authored
commit d847471d upstream Fixes kernel BUG at lib/radix-tree.c:473. Previously the handler was incidentally provided by tmpfs but this was removed with: commit 14fcc23f Author: Hugh Dickins <hugh@veritas.com> Date: Mon Jul 28 15:46:19 2008 -0700 tmpfs: fix kernel BUG in shmem_delete_inode relying on this behaviour was incorrect in any case and the BUG also appeared when the device node was on an ext3 filesystem. v2: override a_ops at open() time rather than mmap() time to minimise races per AKPM's concerns. Signed-off-by:
Ian Campbell <ijc@hellion.org.uk> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Hugh Dickins <hugh@veritas.com> Cc: Johannes Weiner <hannes@saeurebad.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Kel Modderman <kel@otaku42.de> Cc: Markus Armbruster <armbru@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
Matthew Garrett authored
commit f1441318 upstream Date: Wed, 20 Aug 2008 14:08:57 -0700 Subject: eeepc-laptop: fix use after free eeepc-laptop uses the hwmon struct after unregistering the device, causing an oops on module unload. Flip the ordering to fix. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Karol Kozimor <sziwan@users.sourceforge.net> Signed-off-by:
-
Greg Kroah-Hartman authored
commit ebca4f1b upstream Alex Chiang and Matthew Wilcox pointed out that pci_get_dev_by_id() does not properly decrement the reference on the from pointer if it is present, like the documentation for the function states it will. It fixes a pretty bad leak in the hotplug core (we were leaking an entire struct pci_dev for each function of each offlined card, the first time around; subsequent onlines/offlines were ok). Cc: Matthew Wilcox <matthew@wil.cx> Tested-by:
Alex Chiang <achiang@hp.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Al Viro authored
commit 82d63fc9 upstream After commit a97c9bf3 (fix cramfs making duplicate entries in inode cache) in kernel 2.6.14, named-pipe on cramfs does not work properly. It seems the commit make all named-pipe on cramfs share their inode (and named-pipe buffer). Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino == 1 immediately. Reported-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 20 Aug, 2008 32 commits
-
-
Greg Kroah-Hartman authored
-
Suresh Siddha authored
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore() [ Upstream commit: e4914012 ] Wolfgang Walter reported this oops on his via C3 using padlock for AES-encryption: ################################################################## BUG: unable to handle kernel NULL pointer dereference at 000001f0 IP: [<c01028c5>] __switch_to+0x30/0x117 *pde = 00000000 Oops: 0002 [#1] PREEMPT Modules linked in: Pid: 2071, comm: sleep Not tainted (2.6.26 #11) EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0 EIP is at __switch_to+0x30/0x117 EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300 ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000) Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046 c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000 c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0 Call Trace: [<c03b5b43>] ? schedule+0x285/0x2ff [<c0131856>] ? pm_qos_requirement+0x3c/0x53 [<c0239f54>] ? acpi_processor_idle+0x0/0x434 [<c01025fe>] ? cpu_idle+0x73/0x7f [<c03a4dcd>] ? rest_init+0x61/0x63 ======================= Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end() around the padlock instructions fix the oops. Suresh wrote: These padlock instructions though don't use/touch SSE registers, but it behaves similar to other SSE instructions. For example, it might cause DNA faults when cr0.ts is set. While this is a spurious DNA trap, it might cause oops with the recent fpu code changes. This is the code sequence that is probably causing this problem: a) new app is getting exec'd and it is somewhere in between start_thread() and flush_old_exec() in the load_xyz_binary() b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is cleared. c) Now we get an interrupt/softirq which starts using these encrypt/decrypt routines in the network stack. This generates a math fault (as cr0.ts is '1') which sets TS_USEDFPU and restores the math that is in the task's xstate. d) Return to exec code path, which does start_thread() which does free_thread_xstate() and sets xstate pointer to NULL while the TS_USEDFPU is still set. e) At the next context switch from the new exec'd task to another task, we have a scenarios where TS_USEDFPU is set but xstate pointer is null. This can cause an oops during unlazy_fpu() in __switch_to() Now: 1) This should happen with or with out pre-emption. Viro also encountered similar problem with out CONFIG_PREEMPT. 2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because kernel_fpu_begin() will manually do a clts() and won't run in to the situation of setting TS_USEDFPU in step "c" above. 3) This was working before the fpu changes, because its a spurious math fault which doesn't corrupt any fpu/sse registers and the task's math state was always in an allocated state. With out the recent lazy fpu allocation changes, while we don't see oops, there is a possible race still present in older kernels(for example, while kernel is using kernel_fpu_begin() in some optimized clear/copy page and an interrupt/softirq happens which uses these padlock instructions generating DNA fault). This is the failing scenario that existed even before the lazy fpu allocation changes: 0. CPU's TS flag is set 1. kernel using FPU in some optimized copy routine and while doing kernel_fpu_begin() takes an interrupt just before doing clts() 2. Takes an interrupt and ipsec uses padlock instruction. And we take a DNA fault as TS flag is still set. 3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts 4. We complete the padlock routine 5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes the optimized copy routine and does kernel_fpu_end(). At this point, we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll set and not cleared. 6. Now kernel resumes its user operation. And at the next context switch, kernel sees it has do a FP save as TS_USEDFPU is still set and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu() will take a DNA fault, as cr0.ts is '1' and now, because we are in __switch_to(), math_state_restore() will get confused and will restore the next task's FP state and will save it in prev tasks's FP state. Remember, in __switch_to() we are already on the stack of the next task but take a DNA fault for the prev task. This causes the fpu leakage. Fix the padlock instruction usage by calling them inside the context of new routines irq_ts_save/restore(), which clear/restore cr0.ts manually in the interrupt context. This will not generate spurious DNA in the context of the interrupt which will fix the oops encountered and the possible FPU leakage issue. Reported-and-bisected-by:
Wolfgang Walter <wolfgang.walter@stwm.de> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Dean Hildebrand authored
commit 35405f25 upstream BCM5706S wont work correctly unless VPD length truncated to 128 Signed-off-by:
Dean Hildebrand <dhildeb@us.ibm.com> Signed-off-by:
-
Jeff Layton authored
commit 66b8bd3c upstream [CIFS] properly account for new user= field in SPNEGO upcall string allocation ...it doesn't look like it's being accounted for at the moment. Also try to reorganize the calculation to make it a little more evident what each piece means. This should probably go to the stable series as well... Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Alan Stern authored
commit 59f4ff2e upstream This patch (as1119b) will help to reduce the clutter of usb-storage's unusual_devs file by automatically detecting some devices that need the IGNORE_RESIDUE flag. The idea is that devices should never return a non-zero residue for an INQUIRY or a READ CAPACITY command unless they failed to transfer all the requested data. So if one of these commands transfers a standard amount of data but there is a positive residue, we know that the residue is bogus and we can set the flag. This fixes the problems reported in Bugzilla #11125. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Matthew Frost <artusemrys@sbcglobal.net> Signed-off-by:
-
Alan Stern authored
commit f756cbd4 upstream. This patch (as1110) reverts an earlier patch meant to help with Wireless USB host controllers. These controllers can have bulk maxpacket values larger than 512, which puts unusual constraints on the sizes of scatter-gather list elements. However it turns out that the block layer does not provide the support we need to enforce these constraints; merely changing the DMA alignment mask doesn't help. Hence there's no reason to keep the original patch. The Wireless USB problem will have to be solved a different way. In addition, there is a reason to get rid of the earlier patch. By dereferencing a pointer stored in the ep_in array of struct usb_device, the current code risks an invalid memory access when it runs concurrently with device removal. The members of that array are cleared before the driver's disconnect method is called, so it should not try to use them. Signed-off-by:
-
Andrew Vasquez authored
[ Upstream commit 85821c90 ] As there's no point in adding a fixed-fudge value (originally 5 seconds), honor the user settings only. We also remove the driver's dead-callback get_rport_dev_loss_tmo function (qla2x00_get_rport_loss_tmo()). Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Seokmann Ju authored
[ Upstream commit 5f3a9a20 ] Signed-off-by:
Seokmann Ju <seokmann.ju@qlogic.com> Signed-off-by:
-
Joerg Roedel authored
commit 7b27718b upstream yesterday I tried to reactivate my old 486 box and wanted to install a current Linux with latest kernel on it. But it turned out that the latest kernel does not boot because the machine crashes early in the setup code. After some debugging it turned out that the problem is the query_ist() function. If this interrupt with that function is called the machine simply locks up. It looks like a BIOS bug. Looking for a workaround for this problem I wrote the attached patch. It checks for the CPUID instruction and if it is not implemented it does not call the speedstep BIOS function. As far as I know speedstep should be available since some Pentium earliest. Alan Cox observed that it's available since the Pentium II, so cpuid levels 4 and 5 can be excluded altogether. H. Peter Anvin cleaned up the code some more: > Right in concept, but I dislike the implementation (duplication of the > CPU detect code we already have). Could you try this patch and see if > it works for you? which, with a small modification to fix a build error with it the resulting kernel boots on my machine. Signed-off-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
"H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Jan Beulich authored
commit 7bc069c6 upstream The masked difference is what needs to be compared against 1, rather than the difference of masked values (which can be negative). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 6f63e781 ] Things like lockdep can try to do stack backtraces before the irqstack blocks have been setup. So don't try to match their ranges so early on. Also, remove unused variable in save_stack_trace(). Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 4f70f7a9 ] Signed-off-by:
-
David S. Miller authored
[ Upstream commit 5afe2738 ] Record one more level of stack frame program counter. Particularly when lockdep and all sorts of spinlock debugging is enabled, figuring out the caller of spin_lock() is difficult when the cpu is stuck on the lock. Signed-off-by:
-
David S. Miller authored
[ Upstream commit c7498081 ] The calls down into prom_printf() when we detect an overflowed stack can recurse again since the overflow stack will be "below" the current kernel stack limit. Prevent this by just returning straight if we are on the stack overflow safe stack already. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 433c5f70 ] Bug reported by Alexander Beregalov. Before we dereference the stack frame or try to peek at the pt_regs magic value, make sure the entire object is within the kernel stack bounds. Signed-off-by:
-
Larry Finger authored
With the rtl8187 driver, the config routine is not protected against access before a previous call has completed. When this happens, the TX loopback that is needed to change channels may cause the chip to be locked with a reset needed to restore communications. This patch entered mainline as commit 7dcdd073. The problem was found by Herton Ronaldo Krzesinski <herton@mandriva.com.br>, who also suggested this type of fix. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Acked-by:
Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
upstream commit is 24307ffa Based on sparse comments in OpenFirmware code (no Cx5510/Cx5520 datasheet here). This fixes 2.6.26 regression reported by TAKADA and caused by addition of warm-plug support. Tested-by:
TAKADA Yoshihito <takada@mbf.nifty.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
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:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by:
-
Jan Beulich authored
commit 04e1e0cc upstream. 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:
-
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:
-
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:
-
