| Age | Commit message (Collapse) | Author |
|---|
|
|
|
commit cd94154cc6a28dd9dc271042c1a59c08d26da886 upstream.
Git commit 36409f6353fc2d7b6516e631415f938eadd92ffa "use generic RCU
page-table freeing code" introduced a tlb flushing bug. Partially revert
the above git commit and go back to s390 specific page table flush code.
For s390 the TLB can contain three types of entries, "normal" TLB
page-table entries, TLB combined region-and-segment-table (CRST) entries
and real-space entries. Linux does not use real-space entries which
leaves normal TLB entries and CRST entries. The CRST entries are
intermediate steps in the page-table translation called translation paths.
For example a 4K page access in a three-level page table setup will
create two CRST TLB entries and one page-table TLB entry. The advantage
of that approach is that a page access next to the previous one can reuse
the CRST entries and needs just a single read from memory to create the
page-table TLB entry. The disadvantage is that the TLB flushing rules are
more complicated, before any page-table may be freed the TLB needs to be
flushed.
In short: the generic RCU page-table freeing code is incorrect for the
CRST entries, in particular the check for mm_users < 2 is troublesome.
This is applicable to 3.0+ kernels.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a09d431f344d854e4fe9cfac44f78cb8202f3eb7 upstream.
When the force changes went in back in 3.3.0, we ended up returning
disconnected in the !force case, and the connected in when forced,
as it hit the hardcoded check.
Fix it so all exits go via the hardcoded check and stop spurious
modesets on platforms with hardcoded EDIDs.
Reported-by: Evan McNabb (Red Hat)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 16a5e32b83fd946312b9b13590c75d20c95c5202 upstream.
My rv515 card is very flaky with msi enabled. Every so often it loses a rearm
and never comes back, manually banging the rearm brings it back.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e36325071832f1ba96ac54fb8ba1459f08b05dd8 upstream.
The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms:
fix analog load detection on DVI-I connectors] is obviously wrong, and
it's the culprit of the regression on my workstation with DVI-analog
connection resulting in the blank output.
Fixed the typo now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bdbb776f882f5ad431aa1e694c69c1c3d6a4a5b8 upstream.
It was possible to extract the robust list head address from a setuid
process if it had used set_robust_list(), allowing an ASLR info leak. This
changes the permission checks to be the same as those used for similar
info that comes out of /proc.
Running a setuid program that uses robust futexes would have had:
cred->euid != pcred->euid
cred->euid == pcred->uid
so the old permissions check would allow it. I'm not aware of any setuid
programs that use robust futexes, so this is just a preventative measure.
(This patch is based on changes from grsecurity.)
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Serge E. Hallyn <serge.hallyn@canonical.com>
Cc: kernel-hardening@lists.openwall.com
Cc: spender@grsecurity.net
Link: http://lkml.kernel.org/r/20120319231253.GA20893@www.outflux.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 07c0ea874d43c299d185948452945a361052b6e3 upstream.
Add Atheros maryann 0cf3:311d PIDVID support
This module is AR3012 Series.
Include /sys/kernel/debug/usb/devices output here for reference
before:
T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=311d Rev= 0.01
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
after:
T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=311d Rev= 0.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Cho, Yu-Chen <acho@suse.com>
cked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9498ba7a1d38d42eef4ef6d906ab1743c9f0fd6f upstream.
The bluetooth module in the Asus UX31/UX21 is based on Atheros AR3012
and requires a firmware to be uploaded before it's usable.
output of usb-devices for this module:
T: Bus=01 Lev=02 Prnt=02 Port=07 Cnt=03 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3375 Rev=00.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: Eran <eran@over-here.org>
Tested-by: Michal Labedzki <michal.labedzki@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit afbaa90b80b1ec66e5137cc3824746bfdf559b18 upstream.
If a bitmap is added while the array is active, it is possible
for bitmap_daemon_work to run while the bitmap is being
initialised.
This is particularly a problem if bitmap_daemon_work sees
bitmap->filemap as non-NULL before it has been filled in properly.
So hold bitmap_info.mutex while filling in ->filemap
to prevent problems.
This patch is suitable for any -stable kernel, though it might not
apply cleanly before about 3.1.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ca7fe2db892dcf91b2c72ee352eda4ff867903a7 upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c43f1508686e8e4746012bf87995085eeb0f5307 upstream.
Currently, executing suspend/hibernation,
memory access violation occurs.
In pch_dma_save_regs() called by suspend(),
you can see the following code.
static void pch_dma_save_regs(struct pch_dma *pd)
{
snip...
list_for_each_entry_safe(chan, _c, &pd->dma.channels, device_node) {
pd_chan = to_pd_chan(chan);
pd->ch_regs[i].dev_addr = channel_readl(pd_chan, DEV_ADDR);
pd->ch_regs[i].mem_addr = channel_readl(pd_chan, MEM_ADDR);
pd->ch_regs[i].size = channel_readl(pd_chan, SIZE);
pd->ch_regs[i].next = channel_readl(pd_chan, NEXT);
i++;
}
}
Max loop count is 12 defined at pci_table.
So, this caused memory access violation.
This patch fixes the issue
- Modify array size (MAX_CHAN_NR)
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0b052f4a088ddc47a5da23dd733522241314cfb4 upstream.
Currently, Mode-Control register is accessed by read-modify-write.
According to DMA hardware specifications datasheet, prohibits this method.
Because this register resets to 0 by DMA HW after DMA transfer completes.
Thus, current read-modify-write processing can cause unexpected behavior.
The datasheet says in case of writing Mode-Control register, set the value for only target channel, the others must set '11b'.
e.g. Set DMA0=01b DMA11=10b
CTL0=33333331h
CTL2=00002333h
NOTE:
CTL0 includes DMA0~7 Mode-Control register.
CTL2 includes DMA8~11 Mode-Control register.
This patch modifies the issue.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 70f18915846f092e0e1c988f1726a532fa3ab3a1 upstream.
Fix for the following INFO message
=================================
[ INFO: inconsistent lock state ]
2.6.39+ #89
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
rs232/822 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&pd_chan->lock)->rlock){?.....}, at: [<c123b9a1>] pdc_desc_get+0x16/0xab
{HARDIRQ-ON-W} state was registered at:
[<c104fe28>] mark_irqflags+0xbd/0x11a
[<c1050386>] __lock_acquire+0x501/0x6bb
[<c1050945>] lock_acquire+0x63/0x7b
[<c131c51d>] _raw_spin_lock_bh+0x43/0x51
[<c123bee4>] pd_alloc_chan_resources+0x92/0x11e
[<c123ad62>] dma_chan_get+0x9b/0x107
[<c123b2d1>] __dma_request_channel+0x61/0xdc
[<c11ba24b>] pch_request_dma+0x61/0x19e
[<c11bb3b8>] pch_uart_startup+0x16a/0x1a2
[<c11b8446>] uart_startup+0x87/0x147
[<c11b9183>] uart_open+0x117/0x13e
[<c11a5c7d>] tty_open+0x23c/0x34c
[<c1097705>] chrdev_open+0x140/0x15f
[<c10930a6>] __dentry_open.clone.14+0x14a/0x22b
[<c1093dfb>] nameidata_to_filp+0x36/0x40
[<c109f28b>] do_last+0x513/0x635
[<c109f4af>] path_openat+0x9c/0x2aa
[<c109f6e4>] do_filp_open+0x27/0x69
[<c1093f02>] do_sys_open+0xfd/0x184
[<c1093fad>] sys_open+0x24/0x2a
[<c131d58c>] sysenter_do_call+0x12/0x32
irq event stamp: 2522
hardirqs last enabled at (2521): [<c131ca3b>] _raw_spin_unlock_irqrestore+0x36/0x52
hardirqs last disabled at (2522): [<c131db27>] common_interrupt+0x27/0x34
softirqs last enabled at (2354): [<c102fa11>] __do_softirq+0x10a/0x11a
softirqs last disabled at (2299): [<c10041a4>] do_softirq+0x57/0xa4
other info that might help us debug this:
2 locks held by rs232/822:
#0: (&tty->atomic_write_lock){+.+.+.}, at: [<c11a4b7a>] tty_write_lock+0x14/0x3c
#1: (&port_lock_key){-.....}, at: [<c11bad72>] pch_uart_interrupt+0x17/0x1e9
stack backtrace:
Pid: 822, comm: rs232 Not tainted 2.6.39+ #89
Call Trace:
[<c1319f90>] ? printk+0x19/0x1b
[<c104f893>] print_usage_bug+0x184/0x18f
[<c104e5b1>] ? print_irq_inversion_bug+0x10e/0x10e
[<c104f943>] mark_lock_irq+0xa5/0x1f6
[<c104fc9c>] mark_lock+0x208/0x2d7
[<c104fdc0>] mark_irqflags+0x55/0x11a
[<c1050386>] __lock_acquire+0x501/0x6bb
[<c10042ee>] ? dump_trace+0x92/0xb6
[<c1050945>] lock_acquire+0x63/0x7b
[<c123b9a1>] ? pdc_desc_get+0x16/0xab
[<c131c2d0>] _raw_spin_lock+0x3e/0x4c
[<c123b9a1>] ? pdc_desc_get+0x16/0xab
[<c123b9a1>] pdc_desc_get+0x16/0xab
[<c10504d8>] ? __lock_acquire+0x653/0x6bb
[<c123bb2c>] pd_prep_slave_sg+0x7c/0x1cb
[<c1006c3f>] ? nommu_map_sg+0x6e/0x81
[<c11bace6>] dma_handle_tx+0x2cf/0x344
[<c11bad72>] ? pch_uart_interrupt+0x17/0x1e9
[<c11baebb>] pch_uart_interrupt+0x160/0x1e9
[<c10642fb>] handle_irq_event_percpu+0x25/0x127
[<c1064429>] handle_irq_event+0x2c/0x43
[<c1065e0d>] ? handle_fasteoi_irq+0x84/0x84
[<c1065eb9>] handle_edge_irq+0xac/0xce
<IRQ> [<c1003ecb>] ? do_IRQ+0x38/0x9d
[<c131db2e>] ? common_interrupt+0x2e/0x34
[<c105007b>] ? __lock_acquire+0x1f6/0x6bb
[<c131ca3d>] ? _raw_spin_unlock_irqrestore+0x38/0x52
[<c11b798b>] ? uart_start+0x2d/0x32
[<c11b7998>] ? uart_flush_chars+0x8/0xa
[<c11a7962>] ? n_tty_write+0x12c/0x1c6
[<c1027a73>] ? try_to_wake_up+0x251/0x251
[<c11a4d0b>] ? tty_write+0x169/0x1dc
[<c11a7836>] ? n_tty_ioctl+0xb7/0xb7
[<c1094841>] ? vfs_write+0x91/0x10d
[<c11a4ba2>] ? tty_write_lock+0x3c/0x3c
[<c1094a69>] ? sys_write+0x3e/0x63
[<c131d58c>] ? sysenter_do_call+0x12/0x32
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Tested-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c3d4913cd4cd469cbf29d411293e937729e83f3a upstream.
ISSUE: In case PCH_DMA with I2S communications with ch8~ch11, sometimes I2S data
is not send correctly.
CAUSE: The following patch I submitted before was not enough modification for
supporting DMA ch8~ch11. The modification for status register of ch8~11 was not
enough.
pch_dma: Support I2S for ML7213 IOH
author Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Mon, 9 May 2011 07:09:38 +0000 (16:09 +0900)
committer Vinod Koul <vinod.koul@intel.com>
Mon, 9 May 2011 11:42:23 +0000 (16:42 +0530)
commit 194f5f2706c7472f9c6bb2d17fa788993606581f
tree c9d4903ea02b18939a4f390956a48be1a3734517
parent 60092d0bde4c8741198da4a69b693d3709385bf1
This patch fixes the issue.
We can confirm PCH_DMA with I2S communications with ch8~ch11 works well.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 64d91cfaade2155ad048fe3b65238a052e29dde4 upstream.
Currently, ".setup" function is not set.
As a result, when detecting our IOH's uart device without pch_uart, kernel panic
occurs at the following of pciserial_init_ports().
for (i = 0; i < nr_ports; i++) {
if (quirk->setup(priv, board, &serial_port, i))
break;
So, this patch adds the ".setup" function.
We can use pci_default_setup because our IOH's uart is compatible with 16550.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6c4b47d243112e98811ce0da7bbb32cc3857dd1a upstream.
Currently, PCIe bus number is set as fixed value "2".
However, PCIe bus number is not always "2".
This patch sets bus number using probe() parameter.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 51b79bee627d526199b2f6a6bef8ee0c0739b6d1 upstream.
Add missing "personality.h"
security/commoncap.c: In function 'cap_bprm_set_creds':
security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
security/commoncap.c:510: error: (Each undeclared identifier is reported only once
security/commoncap.c:510: error: for each function it appears in.)
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8931d9ea78848b073bf299594f148b83abde4a5e upstream.
Allow referenced objects to be in a different scope.
http://www.acpica.org/bugzilla/show_bug.cgi?id=937
http://marc.info/?l=linux-acpi&m=131636632718222&w=2
ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110112/psargs-359)
ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110112/nsinit-349)
Scope (_SB)
{
Name (RAMB, 0xDF5A1018)
OperationRegion (\RAMW, SystemMemory, RAMB, 0x00010000)
}
For above ASL code, we need to save scope node(\_SB) to lookup
the argument node(\_SB.RAMB).
Reported-by: Jim Green <student.northwestern@gmail.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 731ad81e2dd97e3f222361f7b3ff4b35639e46af upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 833310402c54ad9b676b465fc53ad276b13d36be upstream.
ISSUE:
USB Suspend interrupts occur frequently.
CAUSE:
When it is called pch_udc_reconnect() in USB Suspend, it repeats reset and
Suspend.
SOLUTION:
pch_udc_reconnect() does not enable all interrupts. When an enumeration event
occurred the driver enables all interrupts.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
connect/disconnect issue
commit 1c575d2d2e3ff2a7cb3c2e2165064199cfd8ad32 upstream.
ISSUE:
After a USB cable is connect/disconnected, the system rarely freezes.
CAUSE:
Since the USB device controller cannot know to disconnect the USB cable, when
it is used without detecting VBUS by GPIO, the UDC driver does not notify to
USB Gadget.
Since USB Gadget cannot know to disconnect, a false setting occurred when the
USB cable is connected/disconnect repeatedly.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 84566abba058b2aae8d603dfa90b5a3778a6714f upstream.
ISSUE:
After USB Suspend, a system rarely freezes.
CAUSE:
When USB Suspend occurred, the driver is not notifying
a gadget of the event.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c802672cd36cd063bfd54d54c8c34825ab5b2357 upstream.
ISSUE:
If the return value of pch_udc_pcd_init() is False, the return value of
this function is unsettled.
Since pch_udc_pcd_init() always returns 0, there is not actually the issue.
CAUSE:
If pch_udc_pcd_init() is True, the variable, retval, is not set for an
appropriate value.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c50a3bff0edb0acd49d8033a12ea4668e09a31ad upstream.
ISSUE:
When the driver notifies a gadget of a disconnect event, a system
rarely freezes.
CAUSE:
When the driver calls dev->driver->disconnect(), it is not calling
spin_unlock().
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9914a0de7a27ef2cb5d9aacfe50ae97ebb532f28 upstream.
Currently, external ROM access is enabled/disabled in probe()/remove().
So, when a buggy software access unanticipated memory area,
in case of enabling this ADE bit,
external ROM memory area can be broken.
This patch enables the ADE bit only accessing external ROM area.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Masayuki Ohtak <masa-korg@dsn.okisemi.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit dd7d7fea29c18b818e94f252a76f495490d399c3 upstream.
Only ML7213/ML7223(Bus-n) has this register.
Currently,this driver doesn't care register "FUNCSEL" in suspend/resume.
This patch saves/restores FUNCSEL register only when the device is ML7213 or
ML7223(Bus-n).
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 20ae6d0b307963416db0e8433602e5d5c95e942b upstream.
Register "interrupt delay value" is for GbE which is connected to Bus-m of PCIe.
However currently, the value is set for Bus-n.
As a result, the value is not set correctly.
This patch moves setting the value processing of Bus-n to Bus-m.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 94324962066231a938564bebad0f941cd2d06bb2 upstream.
Make sure hci_dev_open returns immediately if hci_dev_unregister has
been called.
This fixes a race between hci_dev_open and hci_dev_unregister which can
lead to a NULL-pointer dereference.
Bug is 100% reproducible using hciattach and a disconnected serial port:
0. # hciattach -n /dev/ttyO1 any noflow
1. hci_dev_open called from hci_power_on grabs req lock
2. hci_init_req executes but device fails to initialise (times out
eventually)
3. hci_dev_open is called from hci_sock_ioctl and sleeps on req lock
4. hci_uart_tty_close calls hci_dev_unregister and sleeps on req lock in
hci_dev_do_close
5. hci_dev_open (1) releases req lock
6. hci_dev_do_close grabs req lock and returns as device is not up
7. hci_dev_unregister sleeps in destroy_workqueue
8. hci_dev_open (3) grabs req lock, calls hci_init_req and eventually sleeps
9. hci_dev_unregister finishes, while hci_dev_open is still running...
[ 79.627136] INFO: trying to register non-static key.
[ 79.632354] the code is fine but needs lockdep annotation.
[ 79.638122] turning off the locking correctness validator.
[ 79.643920] [<c00188bc>] (unwind_backtrace+0x0/0xf8) from [<c00729c4>] (__lock_acquire+0x1590/0x1ab0)
[ 79.653594] [<c00729c4>] (__lock_acquire+0x1590/0x1ab0) from [<c00733f8>] (lock_acquire+0x9c/0x128)
[ 79.663085] [<c00733f8>] (lock_acquire+0x9c/0x128) from [<c0040a88>] (run_timer_softirq+0x150/0x3ac)
[ 79.672668] [<c0040a88>] (run_timer_softirq+0x150/0x3ac) from [<c003a3b8>] (__do_softirq+0xd4/0x22c)
[ 79.682281] [<c003a3b8>] (__do_softirq+0xd4/0x22c) from [<c003a924>] (irq_exit+0x8c/0x94)
[ 79.690856] [<c003a924>] (irq_exit+0x8c/0x94) from [<c0013a50>] (handle_IRQ+0x34/0x84)
[ 79.699157] [<c0013a50>] (handle_IRQ+0x34/0x84) from [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c)
[ 79.708648] [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c) from [<c037499c>] (__irq_usr+0x3c/0x60)
[ 79.718048] Exception stack(0xcf281fb0 to 0xcf281ff8)
[ 79.723358] 1fa0: 0001e6a0 be8dab00 0001e698 00036698
[ 79.731933] 1fc0: 0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000
[ 79.740509] 1fe0: 0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff
[ 79.747497] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 79.756011] pgd = cf3b4000
[ 79.758850] [00000000] *pgd=8f0c7831, *pte=00000000, *ppte=00000000
[ 79.765502] Internal error: Oops: 80000007 [#1]
[ 79.770294] Modules linked in:
[ 79.773529] CPU: 0 Tainted: G W (3.3.0-rc6-00002-gb5d5c87 #421)
[ 79.781066] PC is at 0x0
[ 79.783721] LR is at run_timer_softirq+0x16c/0x3ac
[ 79.788787] pc : [<00000000>] lr : [<c0040aa4>] psr: 60000113
[ 79.788787] sp : cf281ee0 ip : 00000000 fp : cf280000
[ 79.800903] r10: 00000004 r9 : 00000100 r8 : b6f234d0
[ 79.806427] r7 : c0519c28 r6 : cf093488 r5 : c0561a00 r4 : 00000000
[ 79.813323] r3 : 00000000 r2 : c054eee0 r1 : 00000001 r0 : 00000000
[ 79.820190] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 79.827728] Control: 10c5387d Table: 8f3b4019 DAC: 00000015
[ 79.833801] Process gpsd (pid: 1265, stack limit = 0xcf2802e8)
[ 79.839965] Stack: (0xcf281ee0 to 0xcf282000)
[ 79.844573] 1ee0: 00000002 00000000 c0040a24 00000000 00000002 cf281f08 00200200 00000000
[ 79.853210] 1f00: 00000000 cf281f18 cf281f08 00000000 00000000 00000000 cf281f18 cf281f18
[ 79.861816] 1f20: 00000000 00000001 c056184c 00000000 00000001 b6f234d0 c0561848 00000004
[ 79.870452] 1f40: cf280000 c003a3b8 c051e79c 00000001 00000000 00000100 3fa9e7b8 0000000a
[ 79.879089] 1f60: 00000025 cf280000 00000025 00000000 00000000 b6f234d0 00000000 00000004
[ 79.887756] 1f80: 00000000 c003a924 c053ad38 c0013a50 fa200000 cf281fb0 ffffffff c0008530
[ 79.896362] 1fa0: 0001e6a0 0000aab8 80000010 c037499c 0001e6a0 be8dab00 0001e698 00036698
[ 79.904998] 1fc0: 0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000
[ 79.913665] 1fe0: 0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff 00fbf700 04ffff00
[ 79.922302] [<c0040aa4>] (run_timer_softirq+0x16c/0x3ac) from [<c003a3b8>] (__do_softirq+0xd4/0x22c)
[ 79.931945] [<c003a3b8>] (__do_softirq+0xd4/0x22c) from [<c003a924>] (irq_exit+0x8c/0x94)
[ 79.940582] [<c003a924>] (irq_exit+0x8c/0x94) from [<c0013a50>] (handle_IRQ+0x34/0x84)
[ 79.948913] [<c0013a50>] (handle_IRQ+0x34/0x84) from [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c)
[ 79.958404] [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c) from [<c037499c>] (__irq_usr+0x3c/0x60)
[ 79.967773] Exception stack(0xcf281fb0 to 0xcf281ff8)
[ 79.973083] 1fa0: 0001e6a0 be8dab00 0001e698 00036698
[ 79.981658] 1fc0: 0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000
[ 79.990234] 1fe0: 0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff
[ 79.997161] Code: bad PC value
[ 80.000396] ---[ end trace 6f6739840475f9ee ]---
[ 80.005279] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c7713e736526d8c9f6f87716fb90562a8ffaff2c upstream.
The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in. It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last. I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled. Therefore we need to restore the event ring registers
before we re-enable interrupts.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.
Currently the maximum noise floor limit is set as too high (-60dB). The
assumption of having a higher threshold limit is that it would help
de-sensitize the receiver (reduce phy errors) from continuous
interference. But when we have a bursty interference where there are
collisions and then free air time and if the receiver is desensitized too
much, it will miss the normal packets too. Lets make use of chips
specific min, nom and max limits always. This patch helps to improve the
connection stability in congested networks.
Cc: Paul Stewart <pstew@google.com>
Tested-by: Gary Morain <gmorain@google.com>
Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.0/3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d52fc5dde171f030170a6cb78034d166b13c9445 upstream.
If a process increases permissions using fcaps all of the dangerous
personality flags which are cleared for suid apps should also be cleared.
Thus programs given priviledge with fcaps will continue to have address space
randomization enabled even if the parent tried to disable it to make it
easier to attack.
Signed-off-by: Eric Paris <eparis@redhat.com>
Reviewed-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c3d8b76f61586714cdc5f219ba45592a54caaa55 upstream.
Commit 360f748b204275229f8398cb2f9f53955db1503b
"serial: PL011: clear pending interrupts"
attempts to clear interrupts by writing to a
yet-unassigned memory address. This fixes the issue.
The breaking patch is marked for stable so should be
carried along with the other patch.
Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nico@fluxnic.net>
Reported-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9b96fbacda34079dea0638ee1e92c56286f6114a upstream.
Chanho Min reported that when the boot loader transfers
control to the kernel, there may be pending interrupts
causing the UART to lock up in an eternal loop trying to
pick tokens from the FIFO (since the RX interrupt flag
indicates there are tokens) while in practice there are
no tokens - in fact there is only a pending IRQ flag.
This patch address the issue with a combination of two
patches suggested by Russell King that clears and mask
all interrupts at probe() and clears any pending error
and RX interrupts at port startup time.
We suspect the spurious interrupts are a side-effect of
switching the UART from FIFO to non-FIFO mode.
Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Reported-by: Chanho Min <chanho0207@gmail.com>
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Jong-Sung Kim <neidhard.kim@lge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 457a4f61f9bfc3ae76e5b49f30f25d86bb696f67 upstream.
The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.
This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation
process.
This should be backported to stable kernels as old as 2.6.37,
that contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9
"xhci: Add reset on resume quirk for asrock p67 host".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 95018a53f7653e791bba1f54c8d75d9cb700d1bd upstream.
Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fb3d85bc7193f23c9a564502df95564c49a32c91 upstream.
The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it. No other code in the xHCI successful resume path would
ever restore it either. Fix that.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 159e1fcc9a60fc7daba23ee8fcdb99799de3fe84 upstream.
When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted. We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.
If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers. Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend. The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to
zero.
Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup(). Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4e833c0b87a30798e67f06120cecebef6ee9644c upstream.
While we're at that, define IMAN bitfield to aid readability.
The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it. Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit. Before that commit, we were blindly writing 0x3 to
the register.
This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a36165dbc78b380846b254017a548b9de5 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bcf398537630bf20b4dbe59ba855b69f404c93cf upstream.
This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb->dev to determine whether or nor an URB is
currently active; the completion handler sets urb->dev to NULL.
However the core unlinking routines need to use urb->dev. Since
unlinking always racing with completion, the completion handler must
not clear urb->dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.
This patch fixes the problem by getting rid of the lines that clear
urb->dev after urb has been submitted. As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens. The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Illia Zaitsev <I.Zaitsev@adbglobal.com>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c5d703dcc776cb542b41665f2b7e2ba054efb4a7 upstream.
Just add new device id. 3G works fine, LTE not tested.
Signed-off-by: Anton Samokhvalov <pg83@yandex.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9ac2feb22b5b821d81463bef92698ef7682a3145 upstream.
Re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array
Signed-off-by: Santiago Garcia Mantinan <manty@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ce5c9851855bab190c9a142761d54ba583ab094c upstream.
DTR/RTS should only be raised when changing baudrate from B0 and not on
any baud rate change (> B0).
Reported-by: Søren Holm <sgh@sgh.dk>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a65a6f14dc24a90bde3f5d0073ba2364476200bf upstream.
Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.
A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.
With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:
[ 199.698286] IP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio]
[ 199.698297] *pde = 00000000
[ 199.698303] Oops: 0000 [#1] PREEMPT SMP
[ 199.698313] Modules linked in: ftdi_sio usbserial
[ 199.698323]
[ 199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[ 199.698339] EIP: 0060:[<f811a089>] EFLAGS: 00010286 CPU: 0
[ 199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[ 199.698348] EAX: 0000003e EBX: f5067000 ECX: 00000000 EDX: 80000600
[ 199.698352] ESI: f48d8800 EDI: 00000001 EBP: f515dd54 ESP: f515dcfc
[ 199.698356] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 199.698361] Process ftdi_open (pid: 1146, ti=f515c000 task=f481e040 task.ti=f515c000)
[ 199.698364] Stack:
[ 199.698368] f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[ 199.698387] 00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[ 199.698479] 22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[ 199.698496] Call Trace:
[ 199.698504] [<f806e68e>] ? serial_activate+0x2e/0x70 [usbserial]
[ 199.698511] [<f806e6ab>] serial_activate+0x4b/0x70 [usbserial]
[ 199.698521] [<c126380c>] tty_port_open+0x7c/0xd0
[ 199.698527] [<f806e660>] ? serial_set_termios+0xa0/0xa0 [usbserial]
[ 199.698534] [<f806e76f>] serial_open+0x2f/0x70 [usbserial]
[ 199.698540] [<c125d07c>] tty_open+0x20c/0x510
[ 199.698546] [<c10e9eb7>] chrdev_open+0xe7/0x230
[ 199.698553] [<c10e48f2>] __dentry_open+0x1f2/0x390
[ 199.698559] [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[ 199.698565] [<c10e4b76>] nameidata_to_filp+0x66/0x80
[ 199.698570] [<c10e9dd0>] ? cdev_put+0x20/0x20
[ 199.698576] [<c10f3e08>] do_last+0x198/0x730
[ 199.698581] [<c10f4440>] path_openat+0xa0/0x350
[ 199.698587] [<c10f47d5>] do_filp_open+0x35/0x80
[ 199.698593] [<c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[ 199.698599] [<c10ff110>] ? alloc_fd+0xc0/0x100
[ 199.698605] [<c10f0b72>] ? getname_flags+0x72/0x120
[ 199.698611] [<c10e4450>] do_sys_open+0xf0/0x1c0
[ 199.698617] [<c11fcc08>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 199.698623] [<c10e458e>] sys_open+0x2e/0x40
[ 199.698628] [<c144c990>] sysenter_do_call+0x12/0x36
[ 199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 <0f> b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[ 199.698884] EIP: [<f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:f515dcfc
[ 199.698893] CR2: 0000000000000078
[ 199.698925] ---[ end trace 77c43ec023940cff ]---
Reported-and-tested-by: Ken Huang <csuhgw@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6f103929f8979d2638e58d7f7fda0beefcb8ee7e upstream.
Fix tick_nohz_restart() to not use a stale ktime_t "now" value when
calling tick_do_update_jiffies64(now).
If we reach this point in the loop it means that we crossed a tick
boundary since we grabbed the "now" timestamp, so at this point "now"
refers to a time in the old jiffy, so using the old value for "now" is
incorrect, and is likely to give us a stale jiffies value.
In particular, the first time through the loop the
tick_do_update_jiffies64(now) call is always a no-op, since the
caller, tick_nohz_restart_sched_tick(), will have already called
tick_do_update_jiffies64(now) with that "now" value.
Note that tick_nohz_stop_sched_tick() already uses the correct
approach: when we notice we cross a jiffy boundary, grab a new
timestamp with ktime_get(), and *then* update jiffies.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/1332875377-23014-1-git-send-email-ncardwell@google.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b78f29ca0516266431688c5eb42d39ce42ec039a upstream.
This patch fix the oops below that catched in my machine
[ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
[ 81.609384] uvesafb: protected mode interface info at c000:d350
[ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
[ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
[ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=4915
[ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3
[ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
[ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
[ 81.744171] Oops: 0011 [#1] SMP
[ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
[ 81.744178]
[ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
[ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
[ 81.744187] EIP is at 0xc00cd3b3
[ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
[ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
[ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 81.744195] Process modprobe (pid: 3497, ti=f57f2000 task=f748c600 task.ti=f57f2000)
[ 81.744196] Stack:
[ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
[ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
[ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
[ 81.744210] Call Trace:
[ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
[ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160
[ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
[ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50
[ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550
[ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560
[ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220
[ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0
[ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0
[ 81.744250] [<c129efb4>] vc_resize+0x14/0x20
[ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500
[ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
[ 81.744258] [<c129b378>] visual_init+0xb8/0x150
[ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360
[ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190
[ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50
[ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0
[ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790
[ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0
[ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90
[ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
[ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20
[ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0
[ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40
[ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
[ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20
[ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170
[ 81.744309] [<c12ba731>] __device_attach+0x41/0x50
[ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70
[ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0
[ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90
[ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90
[ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680
[ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60
[ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
[ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
[ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0
[ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
[ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170
[ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
[ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410
[ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
[ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36
[ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
[ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00
[ 81.744391] CR2: 00000000c00cd3b3
[ 81.744393] ---[ end trace 18b2c87c925b54d6 ]---
Signed-off-by: Wang YanQing <udknight@gmail.com>
Cc: Michal Januszewski <spock@gentoo.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 63fa471dd49e9c9ce029d910d1024330d9b1b145 upstream.
When a process exec()'s, all the maps are retired, but we keep the hist
entries around which hold references to those outdated maps.
If the same library gets mapped in for which we have hist entries, a new
map will be created. But when we take a perf entry hit within that map,
we'll find the existing hist entry with the older map.
This causes symbol translations to be done incorrectly. For example,
the perf entry processing will lookup the correct uptodate map entry and
use that to calculate the symbol and DSO relative address. But later
when we update the histogram we'll translate the address using the
outdated map file instead leading to conditions such as out-of-range
offsets in symbol__inc_addr_samples().
Therefore, update the map of the hist_entry dynamically at lookup/
creation time.
Signed-off-by: David S. Miller <davem@davemloft.net>
Link: http://lkml.kernel.org/r/20120327.031418.1220315351537060808.davem@davemloft.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bc67f63650fad6b3478d9ddfd5406d45a95987c9 upstream.
The total number of scatter gather elements in the CISS command
used by the scsi tape code was being cast to a u8, which can hold
at most 255 scatter gather elements. It should have been cast to
a u16. Without this patch the command gets rejected by the controller
since the total scatter gather count did not add up to the right
value resulting in an i/o error.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 395d287526bb60411ff37b19ad9dd38b58ba8732 upstream.
The default is too small (1024 blocks), use h->cciss_max_sectors (8192 blocks)
Without this change, if you try to set the block size of a tape drive above
512*1024, via "mt -f /dev/st0 setblk nnn" where nnn is greater than 524288,
it won't work right.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9e0daff30fd7ecf698e5d20b0fa7f851e427cca5 upstream.
The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().
Register DS using device_initcall() insteal.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3d3eeb2ef26112a200785e5fca58ec58dd33bf1e upstream.
The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path. In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures. The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing. This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.
The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.
The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.
Reported-by: Meelis Roos <mroos@linux.ee>
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
