<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers, branch v2.6.34.15</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>video:uvesafb: Fix oops that uvesafb try to execute NX-protected page</title>
<updated>2014-02-10T21:11:38+00:00</updated>
<author>
<name>Wang YanQing</name>
<email>udknight@gmail.com</email>
</author>
<published>2012-04-01T00:54:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dbe686b56faa362865b54f2e1dfa3ecc88977dd8'/>
<id>dbe686b56faa362865b54f2e1dfa3ecc88977dd8</id>
<content type='text'>
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: [&lt;c00cd3b3&gt;] 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:[&lt;c00cd3b3&gt;] 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]  [&lt;f82512c5&gt;] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
[   81.744222]  [&lt;c124a9bc&gt;] fb_pan_display+0x10c/0x160
[   81.744226]  [&lt;f8251280&gt;] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
[   81.744230]  [&lt;c12598dd&gt;] bit_update_start+0x1d/0x50
[   81.744232]  [&lt;c1255efe&gt;] fbcon_switch+0x39e/0x550
[   81.744235]  [&lt;c125a21a&gt;] ? bit_cursor+0x4ea/0x560
[   81.744240]  [&lt;c129b6cb&gt;] redraw_screen+0x12b/0x220
[   81.744245]  [&lt;c128843b&gt;] ? tty_do_resize+0x3b/0xc0
[   81.744247]  [&lt;c129ef42&gt;] vc_do_resize+0x3d2/0x3e0
[   81.744250]  [&lt;c129efb4&gt;] vc_resize+0x14/0x20
[   81.744253]  [&lt;c12586bd&gt;] fbcon_init+0x29d/0x500
[   81.744255]  [&lt;c12984c4&gt;] ? set_inverse_trans_unicode+0xe4/0x110
[   81.744258]  [&lt;c129b378&gt;] visual_init+0xb8/0x150
[   81.744261]  [&lt;c129c16c&gt;] bind_con_driver+0x16c/0x360
[   81.744264]  [&lt;c129b47e&gt;] ? register_con_driver+0x6e/0x190
[   81.744267]  [&lt;c129c3a1&gt;] take_over_console+0x41/0x50
[   81.744269]  [&lt;c1257b7a&gt;] fbcon_takeover+0x6a/0xd0
[   81.744272]  [&lt;c12594b8&gt;] fbcon_event_notify+0x758/0x790
[   81.744277]  [&lt;c10929e2&gt;] notifier_call_chain+0x42/0xb0
[   81.744280]  [&lt;c1092d30&gt;] __blocking_notifier_call_chain+0x60/0x90
[   81.744283]  [&lt;c1092d7a&gt;] blocking_notifier_call_chain+0x1a/0x20
[   81.744285]  [&lt;c124a5a1&gt;] fb_notifier_call_chain+0x11/0x20
[   81.744288]  [&lt;c124b759&gt;] register_framebuffer+0x1d9/0x2b0
[   81.744293]  [&lt;c1061c73&gt;] ? ioremap_wc+0x33/0x40
[   81.744298]  [&lt;f82537c6&gt;] uvesafb_probe+0xaba/0xc40 [uvesafb]
[   81.744302]  [&lt;c12bb81f&gt;] platform_drv_probe+0xf/0x20
[   81.744306]  [&lt;c12ba558&gt;] driver_probe_device+0x68/0x170
[   81.744309]  [&lt;c12ba731&gt;] __device_attach+0x41/0x50
[   81.744313]  [&lt;c12b9088&gt;] bus_for_each_drv+0x48/0x70
[   81.744316]  [&lt;c12ba7f3&gt;] device_attach+0x83/0xa0
[   81.744319]  [&lt;c12ba6f0&gt;] ? __driver_attach+0x90/0x90
[   81.744321]  [&lt;c12b991f&gt;] bus_probe_device+0x6f/0x90
[   81.744324]  [&lt;c12b8a45&gt;] device_add+0x5e5/0x680
[   81.744329]  [&lt;c122a1a3&gt;] ? kvasprintf+0x43/0x60
[   81.744332]  [&lt;c121e6e4&gt;] ? kobject_set_name_vargs+0x64/0x70
[   81.744335]  [&lt;c121e6e4&gt;] ? kobject_set_name_vargs+0x64/0x70
[   81.744339]  [&lt;c12bbe9f&gt;] platform_device_add+0xff/0x1b0
[   81.744343]  [&lt;f8252906&gt;] uvesafb_init+0x50/0x9b [uvesafb]
[   81.744346]  [&lt;c100111f&gt;] do_one_initcall+0x2f/0x170
[   81.744350]  [&lt;f82528b6&gt;] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
[   81.744355]  [&lt;c10c6994&gt;] sys_init_module+0xf4/0x1410
[   81.744359]  [&lt;c1157fc0&gt;] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
[   81.744363]  [&lt;c144cb10&gt;] 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 &lt;60&gt; e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
[   81.744388] EIP: [&lt;c00cd3b3&gt;] 0xc00cd3b3 SS:ESP 0068:f57f3a00
[   81.744391] CR2: 00000000c00cd3b3
[   81.744393] ---[ end trace 18b2c87c925b54d6 ]---

Signed-off-by: Wang YanQing &lt;udknight@gmail.com&gt;
Cc: Michal Januszewski &lt;spock@gentoo.org&gt;
Cc: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Signed-off-by: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: [&lt;c00cd3b3&gt;] 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:[&lt;c00cd3b3&gt;] 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]  [&lt;f82512c5&gt;] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
[   81.744222]  [&lt;c124a9bc&gt;] fb_pan_display+0x10c/0x160
[   81.744226]  [&lt;f8251280&gt;] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
[   81.744230]  [&lt;c12598dd&gt;] bit_update_start+0x1d/0x50
[   81.744232]  [&lt;c1255efe&gt;] fbcon_switch+0x39e/0x550
[   81.744235]  [&lt;c125a21a&gt;] ? bit_cursor+0x4ea/0x560
[   81.744240]  [&lt;c129b6cb&gt;] redraw_screen+0x12b/0x220
[   81.744245]  [&lt;c128843b&gt;] ? tty_do_resize+0x3b/0xc0
[   81.744247]  [&lt;c129ef42&gt;] vc_do_resize+0x3d2/0x3e0
[   81.744250]  [&lt;c129efb4&gt;] vc_resize+0x14/0x20
[   81.744253]  [&lt;c12586bd&gt;] fbcon_init+0x29d/0x500
[   81.744255]  [&lt;c12984c4&gt;] ? set_inverse_trans_unicode+0xe4/0x110
[   81.744258]  [&lt;c129b378&gt;] visual_init+0xb8/0x150
[   81.744261]  [&lt;c129c16c&gt;] bind_con_driver+0x16c/0x360
[   81.744264]  [&lt;c129b47e&gt;] ? register_con_driver+0x6e/0x190
[   81.744267]  [&lt;c129c3a1&gt;] take_over_console+0x41/0x50
[   81.744269]  [&lt;c1257b7a&gt;] fbcon_takeover+0x6a/0xd0
[   81.744272]  [&lt;c12594b8&gt;] fbcon_event_notify+0x758/0x790
[   81.744277]  [&lt;c10929e2&gt;] notifier_call_chain+0x42/0xb0
[   81.744280]  [&lt;c1092d30&gt;] __blocking_notifier_call_chain+0x60/0x90
[   81.744283]  [&lt;c1092d7a&gt;] blocking_notifier_call_chain+0x1a/0x20
[   81.744285]  [&lt;c124a5a1&gt;] fb_notifier_call_chain+0x11/0x20
[   81.744288]  [&lt;c124b759&gt;] register_framebuffer+0x1d9/0x2b0
[   81.744293]  [&lt;c1061c73&gt;] ? ioremap_wc+0x33/0x40
[   81.744298]  [&lt;f82537c6&gt;] uvesafb_probe+0xaba/0xc40 [uvesafb]
[   81.744302]  [&lt;c12bb81f&gt;] platform_drv_probe+0xf/0x20
[   81.744306]  [&lt;c12ba558&gt;] driver_probe_device+0x68/0x170
[   81.744309]  [&lt;c12ba731&gt;] __device_attach+0x41/0x50
[   81.744313]  [&lt;c12b9088&gt;] bus_for_each_drv+0x48/0x70
[   81.744316]  [&lt;c12ba7f3&gt;] device_attach+0x83/0xa0
[   81.744319]  [&lt;c12ba6f0&gt;] ? __driver_attach+0x90/0x90
[   81.744321]  [&lt;c12b991f&gt;] bus_probe_device+0x6f/0x90
[   81.744324]  [&lt;c12b8a45&gt;] device_add+0x5e5/0x680
[   81.744329]  [&lt;c122a1a3&gt;] ? kvasprintf+0x43/0x60
[   81.744332]  [&lt;c121e6e4&gt;] ? kobject_set_name_vargs+0x64/0x70
[   81.744335]  [&lt;c121e6e4&gt;] ? kobject_set_name_vargs+0x64/0x70
[   81.744339]  [&lt;c12bbe9f&gt;] platform_device_add+0xff/0x1b0
[   81.744343]  [&lt;f8252906&gt;] uvesafb_init+0x50/0x9b [uvesafb]
[   81.744346]  [&lt;c100111f&gt;] do_one_initcall+0x2f/0x170
[   81.744350]  [&lt;f82528b6&gt;] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
[   81.744355]  [&lt;c10c6994&gt;] sys_init_module+0xf4/0x1410
[   81.744359]  [&lt;c1157fc0&gt;] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
[   81.744363]  [&lt;c144cb10&gt;] 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 &lt;60&gt; e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
[   81.744388] EIP: [&lt;c00cd3b3&gt;] 0xc00cd3b3 SS:ESP 0068:f57f3a00
[   81.744391] CR2: 00000000c00cd3b3
[   81.744393] ---[ end trace 18b2c87c925b54d6 ]---

Signed-off-by: Wang YanQing &lt;udknight@gmail.com&gt;
Cc: Michal Januszewski &lt;spock@gentoo.org&gt;
Cc: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Signed-off-by: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs</title>
<updated>2014-02-10T21:11:38+00:00</updated>
<author>
<name>Thomas Jarosch</name>
<email>thomas.jarosch@intra2net.com</email>
</author>
<published>2011-12-07T21:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f126b9e7d62a13fea31fdfeab2e471935326ee09'/>
<id>f126b9e7d62a13fea31fdfeab2e471935326ee09</id>
<content type='text'>
commit cdb1f35dc7de42802527140a3613871c394548e1 upstream.

commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.

Some BIOS implementations leave the Intel GPU interrupts enabled,
even though no one is handling them (f.e. i915 driver is never loaded).
Additionally the interrupt destination is not set up properly
and the interrupt ends up -somewhere-.

These spurious interrupts are "sticky" and the kernel disables
the (shared) interrupt line after 100.000+ generated interrupts.

Fix it by disabling the still enabled interrupts.
This resolves crashes often seen on monitor unplug.

Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash.
  Probably the IRQ ends up somewhere unnoticed.

According to reports on the net, the Intel DH61WW board is also affected.

Many thanks to Jesse Barnes from Intel for helping
with the register configuration and to Intel in general
for providing public hardware documentation.

Signed-off-by: Thomas Jarosch &lt;thomas.jarosch@intra2net.com&gt;
Tested-by: Charlie Suffin &lt;charlie.suffin@stratus.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cdb1f35dc7de42802527140a3613871c394548e1 upstream.

commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.

Some BIOS implementations leave the Intel GPU interrupts enabled,
even though no one is handling them (f.e. i915 driver is never loaded).
Additionally the interrupt destination is not set up properly
and the interrupt ends up -somewhere-.

These spurious interrupts are "sticky" and the kernel disables
the (shared) interrupt line after 100.000+ generated interrupts.

Fix it by disabling the still enabled interrupts.
This resolves crashes often seen on monitor unplug.

Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash.
  Probably the IRQ ends up somewhere unnoticed.

According to reports on the net, the Intel DH61WW board is also affected.

Many thanks to Jesse Barnes from Intel for helping
with the register configuration and to Intel in general
for providing public hardware documentation.

Signed-off-by: Thomas Jarosch &lt;thomas.jarosch@intra2net.com&gt;
Tested-by: Charlie Suffin &lt;charlie.suffin@stratus.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)</title>
<updated>2014-02-10T21:11:37+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2012-06-22T06:25:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=177fa7d76336190ee4ac544ab45fb0dde5b499b2'/>
<id>177fa7d76336190ee4ac544ab45fb0dde5b499b2</id>
<content type='text'>
commit 57fc2e335fd3c2f898ee73570dc81426c28dc7b4 upstream.

Rapid ata hotplug on a libsas controller results in cases where libsas
is waiting indefinitely on eh to perform an ata probe.

A race exists between scsi_schedule_eh() and scsi_restart_operations()
in the case when scsi_restart_operations() issues i/o to other devices
in the sas domain.  When this happens the host state transitions from
SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
-&gt;host_busy is non-zero so we put the eh thread to sleep even though
-&gt;host_eh_scheduled is active.

Before putting the error handler to sleep we need to check if the
host_state needs to return to SHOST_RECOVERY for another trip through
eh.  Since i/o that is released by scsi_restart_operations has been
blocked for at least one eh cycle, this implementation allows those
i/o's to run before another eh cycle starts to discourage hung task
timeouts.

Reported-by: Tom Jackson &lt;thomas.p.jackson@intel.com&gt;
Tested-by: Tom Jackson &lt;thomas.p.jackson@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 57fc2e335fd3c2f898ee73570dc81426c28dc7b4 upstream.

Rapid ata hotplug on a libsas controller results in cases where libsas
is waiting indefinitely on eh to perform an ata probe.

A race exists between scsi_schedule_eh() and scsi_restart_operations()
in the case when scsi_restart_operations() issues i/o to other devices
in the sas domain.  When this happens the host state transitions from
SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
-&gt;host_busy is non-zero so we put the eh thread to sleep even though
-&gt;host_eh_scheduled is active.

Before putting the error handler to sleep we need to check if the
host_state needs to return to SHOST_RECOVERY for another trip through
eh.  Since i/o that is released by scsi_restart_operations has been
blocked for at least one eh cycle, this implementation allows those
i/o's to run before another eh cycle starts to discourage hung task
timeouts.

Reported-by: Tom Jackson &lt;thomas.p.jackson@intel.com&gt;
Tested-by: Tom Jackson &lt;thomas.p.jackson@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: libsas: fix sas_discover_devices return code handling</title>
<updated>2014-02-10T21:11:37+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2012-06-22T06:36:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c3997b4070ddc798cd9906f3e64de2d184af6086'/>
<id>c3997b4070ddc798cd9906f3e64de2d184af6086</id>
<content type='text'>
commit e69e5d3d25d6b58543f782a515baeda064e2b601 upstream.

commit b17caa174a7e1fd2e17b26e210d4ee91c4c28b37 upstream.

commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_discover_dev()
commit 19252de6 [SCSI] libsas: fix wide port hotplug issues

The above commits seem to have confused the return value of
sas_ex_discover_dev which is non-zero on failure and
sas_ex_join_wide_port which just indicates short circuiting discovery on
already established ports.  The result is random discovery failures
depending on configuration.

Calls to sas_ex_join_wide_port are the source of the trouble as its
return value is errantly assigned to 'res'.  Convert it to bool and stop
returning its result up the stack.

Tested-by: Dan Melnic &lt;dan.melnic@amd.com&gt;
Reported-by: Dan Melnic &lt;dan.melnic@amd.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Reviewed-by: Jack Wang &lt;jack_wang@usish.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e69e5d3d25d6b58543f782a515baeda064e2b601 upstream.

commit b17caa174a7e1fd2e17b26e210d4ee91c4c28b37 upstream.

commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_discover_dev()
commit 19252de6 [SCSI] libsas: fix wide port hotplug issues

The above commits seem to have confused the return value of
sas_ex_discover_dev which is non-zero on failure and
sas_ex_join_wide_port which just indicates short circuiting discovery on
already established ports.  The result is random discovery failures
depending on configuration.

Calls to sas_ex_join_wide_port are the source of the trouble as its
return value is errantly assigned to 'res'.  Convert it to bool and stop
returning its result up the stack.

Tested-by: Dan Melnic &lt;dan.melnic@amd.com&gt;
Reported-by: Dan Melnic &lt;dan.melnic@amd.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Reviewed-by: Jack Wang &lt;jack_wang@usish.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libsas: continue revalidation</title>
<updated>2014-02-10T21:11:36+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2012-06-22T06:36:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7888dfe3f5d02cce3c82b1f99cedb460983e4b4b'/>
<id>7888dfe3f5d02cce3c82b1f99cedb460983e4b4b</id>
<content type='text'>
commit 26f2f199ff150d8876b2641c41e60d1c92d2fb81 upstream.

Continue running revalidation until no more broadcast devices are
discovered.  Fixes cases where re-discovery completes too early in a
domain with multiple expanders with pending re-discovery events.
Servicing BCNs can get backed up behind error recovery.

Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 26f2f199ff150d8876b2641c41e60d1c92d2fb81 upstream.

Continue running revalidation until no more broadcast devices are
discovered.  Fixes cases where re-discovery completes too early in a
domain with multiple expanders with pending re-discovery events.
Servicing BCNs can get backed up behind error recovery.

Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Avoid dangling pointer in scsi_requeue_command()</title>
<updated>2014-02-10T21:11:36+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2012-06-29T15:34:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=425f11f628631c26ebc4dfe0dabb77e0eb4643af'/>
<id>425f11f628631c26ebc4dfe0dabb77e0eb4643af</id>
<content type='text'>
commit 940f5d47e2f2e1fa00443921a0abf4822335b54d upstream.

When we call scsi_unprep_request() the command associated with the request
gets destroyed and therefore drops its reference on the device.  If this was
the only reference, the device may get released and we end up with a NULL
pointer deref when we call blk_requeue_request.

Reported-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Reviewed-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Reviewed-by: Tejun Heo &lt;tj@kernel.org&gt;
[jejb: enhance commend and add commit log for stable]
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 940f5d47e2f2e1fa00443921a0abf4822335b54d upstream.

When we call scsi_unprep_request() the command associated with the request
gets destroyed and therefore drops its reference on the device.  If this was
the only reference, the device may get released and we end up with a NULL
pointer deref when we call blk_requeue_request.

Reported-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Reviewed-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Reviewed-by: Tejun Heo &lt;tj@kernel.org&gt;
[jejb: enhance commend and add commit log for stable]
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pcdp: use early_ioremap/early_iounmap to access pcdp table</title>
<updated>2014-02-10T21:11:35+00:00</updated>
<author>
<name>Greg Pearson</name>
<email>greg.pearson@hp.com</email>
</author>
<published>2012-07-30T21:39:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a4e83523250937f22d079b483ac313e71f85881a'/>
<id>a4e83523250937f22d079b483ac313e71f85881a</id>
<content type='text'>
commit 6c4088ac3a4d82779903433bcd5f048c58fb1aca upstream.

efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP
EFI system table and setup an early console for printk output.  The
routine uses ioremap/iounmap to setup access to the HCDP/PCDP table
information.

The call to ioremap is happening early in the boot process which leads
to a panic on x86_64 systems:

    panic+0x01ca
    do_exit+0x043c
    oops_end+0x00a7
    no_context+0x0119
    __bad_area_nosemaphore+0x0138
    bad_area_nosemaphore+0x000e
    do_page_fault+0x0321
    page_fault+0x0020
    reserve_memtype+0x02a1
    __ioremap_caller+0x0123
    ioremap_nocache+0x0012
    efi_setup_pcdp_console+0x002b
    setup_arch+0x03a9
    start_kernel+0x00d4
    x86_64_start_reservations+0x012c
    x86_64_start_kernel+0x00fe

This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console()
with calls to early_ioremap/early_iounmap which can be called during
early boot.

This patch was tested on an x86_64 prototype system which uses the
HCDP/PCDP table for early console setup.

Signed-off-by: Greg Pearson &lt;greg.pearson@hp.com&gt;
Acked-by: Khalid Aziz &lt;khalid.aziz@hp.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6c4088ac3a4d82779903433bcd5f048c58fb1aca upstream.

efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP
EFI system table and setup an early console for printk output.  The
routine uses ioremap/iounmap to setup access to the HCDP/PCDP table
information.

The call to ioremap is happening early in the boot process which leads
to a panic on x86_64 systems:

    panic+0x01ca
    do_exit+0x043c
    oops_end+0x00a7
    no_context+0x0119
    __bad_area_nosemaphore+0x0138
    bad_area_nosemaphore+0x000e
    do_page_fault+0x0321
    page_fault+0x0020
    reserve_memtype+0x02a1
    __ioremap_caller+0x0123
    ioremap_nocache+0x0012
    efi_setup_pcdp_console+0x002b
    setup_arch+0x03a9
    start_kernel+0x00d4
    x86_64_start_reservations+0x012c
    x86_64_start_kernel+0x00fe

This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console()
with calls to early_ioremap/early_iounmap which can be called during
early boot.

This patch was tested on an x86_64 prototype system which uses the
HCDP/PCDP table for early console setup.

Signed-off-by: Greg Pearson &lt;greg.pearson@hp.com&gt;
Acked-by: Khalid Aziz &lt;khalid.aziz@hp.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: cafe_nand: fix an &amp; vs | mistake</title>
<updated>2014-02-10T21:11:33+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2012-06-09T16:08:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=55a95b59f4728dd3739accd091cd9a775870abc0'/>
<id>55a95b59f4728dd3739accd091cd9a775870abc0</id>
<content type='text'>
commit 48f8b641297df49021093763a3271119a84990a2 upstream.

The intent here was clearly to set result to true if the 0x40000000 flag
was set.  But instead there was a | vs &amp; typo and we always set result
to true.

Artem: check the spec at
wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
and this fix looks correct.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 48f8b641297df49021093763a3271119a84990a2 upstream.

The intent here was clearly to set result to true if the 0x40000000 flag
was set.  But instead there was a | vs &amp; typo and we always set result
to true.

Artem: check the spec at
wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
and this fix looks correct.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usbdevfs: Correct amount of data copied to user in processcompl_compat</title>
<updated>2014-02-10T21:11:24+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2012-07-04T07:18:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d4a80d611a9b7d9c8b605325b17d422fb0cd6fe7'/>
<id>d4a80d611a9b7d9c8b605325b17d422fb0cd6fe7</id>
<content type='text'>
commit 2102e06a5f2e414694921f23591f072a5ba7db9f upstream.

iso data buffers may have holes in them if some packets were short, so for
iso urbs we should always copy the entire buffer, just like the regular
processcompl does.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2102e06a5f2e414694921f23591f072a5ba7db9f upstream.

iso data buffers may have holes in them if some packets were short, so for
iso urbs we should always copy the entire buffer, just like the regular
processcompl does.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: serial: fix race between probe and open</title>
<updated>2014-02-10T21:11:23+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2012-03-20T15:59:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=93206d0617751590deab8fd4615280117fea8cc5'/>
<id>93206d0617751590deab8fd4615280117fea8cc5</id>
<content type='text'>
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: [&lt;f811a089&gt;] 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:[&lt;f811a089&gt;] 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]  [&lt;f806e68e&gt;] ? serial_activate+0x2e/0x70 [usbserial]
[  199.698511]  [&lt;f806e6ab&gt;] serial_activate+0x4b/0x70 [usbserial]
[  199.698521]  [&lt;c126380c&gt;] tty_port_open+0x7c/0xd0
[  199.698527]  [&lt;f806e660&gt;] ? serial_set_termios+0xa0/0xa0 [usbserial]
[  199.698534]  [&lt;f806e76f&gt;] serial_open+0x2f/0x70 [usbserial]
[  199.698540]  [&lt;c125d07c&gt;] tty_open+0x20c/0x510
[  199.698546]  [&lt;c10e9eb7&gt;] chrdev_open+0xe7/0x230
[  199.698553]  [&lt;c10e48f2&gt;] __dentry_open+0x1f2/0x390
[  199.698559]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698565]  [&lt;c10e4b76&gt;] nameidata_to_filp+0x66/0x80
[  199.698570]  [&lt;c10e9dd0&gt;] ? cdev_put+0x20/0x20
[  199.698576]  [&lt;c10f3e08&gt;] do_last+0x198/0x730
[  199.698581]  [&lt;c10f4440&gt;] path_openat+0xa0/0x350
[  199.698587]  [&lt;c10f47d5&gt;] do_filp_open+0x35/0x80
[  199.698593]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698599]  [&lt;c10ff110&gt;] ? alloc_fd+0xc0/0x100
[  199.698605]  [&lt;c10f0b72&gt;] ? getname_flags+0x72/0x120
[  199.698611]  [&lt;c10e4450&gt;] do_sys_open+0xf0/0x1c0
[  199.698617]  [&lt;c11fcc08&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
[  199.698623]  [&lt;c10e458e&gt;] sys_open+0x2e/0x40
[  199.698628]  [&lt;c144c990&gt;] 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 &lt;0f&gt; b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[  199.698884] EIP: [&lt;f811a089&gt;] 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 &lt;csuhgw@gmail.com&gt;
Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: [&lt;f811a089&gt;] 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:[&lt;f811a089&gt;] 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]  [&lt;f806e68e&gt;] ? serial_activate+0x2e/0x70 [usbserial]
[  199.698511]  [&lt;f806e6ab&gt;] serial_activate+0x4b/0x70 [usbserial]
[  199.698521]  [&lt;c126380c&gt;] tty_port_open+0x7c/0xd0
[  199.698527]  [&lt;f806e660&gt;] ? serial_set_termios+0xa0/0xa0 [usbserial]
[  199.698534]  [&lt;f806e76f&gt;] serial_open+0x2f/0x70 [usbserial]
[  199.698540]  [&lt;c125d07c&gt;] tty_open+0x20c/0x510
[  199.698546]  [&lt;c10e9eb7&gt;] chrdev_open+0xe7/0x230
[  199.698553]  [&lt;c10e48f2&gt;] __dentry_open+0x1f2/0x390
[  199.698559]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698565]  [&lt;c10e4b76&gt;] nameidata_to_filp+0x66/0x80
[  199.698570]  [&lt;c10e9dd0&gt;] ? cdev_put+0x20/0x20
[  199.698576]  [&lt;c10f3e08&gt;] do_last+0x198/0x730
[  199.698581]  [&lt;c10f4440&gt;] path_openat+0xa0/0x350
[  199.698587]  [&lt;c10f47d5&gt;] do_filp_open+0x35/0x80
[  199.698593]  [&lt;c144bfec&gt;] ? _raw_spin_unlock+0x2c/0x50
[  199.698599]  [&lt;c10ff110&gt;] ? alloc_fd+0xc0/0x100
[  199.698605]  [&lt;c10f0b72&gt;] ? getname_flags+0x72/0x120
[  199.698611]  [&lt;c10e4450&gt;] do_sys_open+0xf0/0x1c0
[  199.698617]  [&lt;c11fcc08&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
[  199.698623]  [&lt;c10e458e&gt;] sys_open+0x2e/0x40
[  199.698628]  [&lt;c144c990&gt;] 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 &lt;0f&gt; b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[  199.698884] EIP: [&lt;f811a089&gt;] 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 &lt;csuhgw@gmail.com&gt;
Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
