- 22 5月, 2009 2 次提交
-
-
由 Corey Minyard 提交于
Instead of queuing IPMB messages before channel initialization, just throw them away. Nobody will be listening for them at this point, anyway, and they will clog up the queue and nothing will be delivered if we queue them. Also set the current channel to the number of channels, as this value is used to tell if the channel information has been initialized. Signed-off-by: NCorey Minyard <cminyard@mvista.com> Cc: Ferenc Wagner <wferi@niif.hu> Cc: Dan Frazier <dannf@hp.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Magnus Damm 提交于
This patch fixes the LCDC driver to avoid calling the function sh_mobile_lcdc_start_stop(priv, 0) unless the same function has been called before to start the LCDC hardware. Triggered when sh_mobile_lcdcfb.c failed to probe() due to missing MSTP clocks. Signed-off-by: NMagnus Damm <damm@igel.co.jp> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
- 21 5月, 2009 2 次提交
-
-
由 Alessandro Rubini 提交于
The second argument of the probe method points to the amba_id structure, so it's better passed with the correct type. None of the current in-tree drivers uses the pointer, so they have only been checked for a clean compile. Change suggested by Russell King. Signed-off-by: NAlessandro Rubini <rubini@unipv.it> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Michel Dänzer 提交于
Fixes a regression from commit 9d5b3ffc ('drm: fixup some of the ioctl function exit paths'): The vblank ioctl needs to update the userspace parameters when interrupted by a signal, which was prevented by the return code check. This could cause the X server to hang in drmWaitVBlank(). Signed-off-by: NMichel Dänzer <daenzer@vmware.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 20 5月, 2009 7 次提交
-
-
由 Roel Kluin 提交于
Do not go beyond ARRAY_SIZE of viocd_diskinfo Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
由 Benjamin Herrenschmidt 提交于
Currently, userspace can fail to obtain the SAREA mapping (among other reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the page size. This breaks for example on PowerPC with 64K pages and radeon despite the kernel radeon actually doing the right rouding in the first place. The way SAREA_MAX is defined with a bunch of ifdef's and duplicated between libdrm and the X server is gross, ultimately it should be retrieved by userspace from the kernel, but in the meantime, we have plenty of existing userspace built with bad values that need to work. This patch works around broken userspace by rounding the requested size in drm_addmap_core() of any SHM map to the page size. Since the backing memory for SHM maps is also allocated within addmap_core, there is no danger of adjacent memory being exposed due to the increased map size. The only side effect is that drivers that previously tried to create or access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL), will now succeed at the cost of a little bit more memory used if that happens to be when the map is created. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Eric Paris 提交于
get_event_name uses sprintf to fill a buffer declared on the stack. It fills the buffer 2 bytes at a time. What the code doesn't take into account is that sprintf(buf, "%02x", data) actually writes 3 bytes. 2 bytes for the data and then it nul terminates the string. Since we declare buf to be 40 characters long and then we write 40 bytes of data into buf sprintf is going to write 41 characters. The fix is to leave room in buf for the nul terminator. Signed-off-by: NEric Paris <eparis@redhat.com> Signed-off-by: NJames Morris <jmorris@namei.org>
-
由 Rafael J. Wysocki 提交于
Recent PCI PM changes introduced a bug that causes some devices to be mishandled after kexec and during early initialization. The failure scenario in the kexec case is the following: * Assume a PCI device is not power-manageable by the platform and has PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR. * The device is put into D3 before kexec (using the native PCI PM). * After kexec, pci_setup_device() sets the device's power state to PCI_UNKNOWN. * pci_set_power_state(dev, PCI_D0) is called by the device's driver. * __pci_start_power_transition(dev, PCI_D0) is called and since the device is not power-manageable by the platform, it causes pci_update_current_state(dev, PCI_D0) to be called. As a result the device's current_state field is updated to PCI_D3, in accordance with the contents of its PCI PM registers. * pci_raw_set_power_state() is called and it changes the device power state to D0. *However*, it should also call pci_restore_bars() to reinitialize the device, but it doesn't, because the device's current_state field has been modified earlier. To prevent this from happening, modify pci_platform_power_transition() so that it doesn't use pci_update_current_state() to update the current_state field for devices that aren't power-manageable by the platform. Instead, this field should be updated directly for devices that don't support the native PCI PM. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Nelson Castillo 提交于
Without this change Openmoko Freerunner (GTA02) bootstrap will deadlock. As pointed out in other patches this issue is in the wild since the merge of: : commit 3aa551c9 : Author: Thomas Gleixner <tglx@linutronix.de> : Date: Mon Mar 23 18:28:15 2009 +0100 : : genirq: add threaded interrupt handler support : : Add support for threaded interrupt handlers Signed-off-by: NNelson Castillo <arhuaco@freaks-unidos.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: <balajirrao@openmoko.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Mark Brown 提交于
Due to the way that the WM8350 audio driver handles CODEC_ENA many of the WM8350 audio registers are marked as volatile when they aren't actually so. Allow the audio driver to see a cache of these values for inspection during interrupt context. To do this we need to stop satisfying any bits from volatile registers from cache - there's no real benefit from doing so anyway, we did the read already. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Linus Torvalds 提交于
Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: NMartin Knoblauch <spamtrap@knobisoft.de> Cc: Matt Mackall <mpm@selenic.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 19 5月, 2009 3 次提交
-
-
由 Ian Campbell 提交于
Currently blkfront gives a warning when hot unplugging due to calling del_gendisk() with interrupts disabled (due to blkif_io_lock). WARNING: at kernel/softirq.c:124 local_bh_enable+0x36/0x84() Modules linked in: xenfs xen_netfront ext3 jbd mbcache xen_blkfront Pid: 13, comm: xenwatch Not tainted 2.6.29-xs5.5.0.13 #3 Call Trace: [<c012611c>] warn_slowpath+0x80/0xb6 [<c0104cf1>] xen_sched_clock+0x16/0x63 [<c0104710>] xen_force_evtchn_callback+0xc/0x10 [<c0104e32>] check_events+0x8/0xe [<c0104d9b>] xen_restore_fl_direct_end+0x0/0x1 [<c0103749>] xen_mc_flush+0x10a/0x13f [<c0105bd2>] __switch_to+0x114/0x14e [<c011d92b>] dequeue_task+0x62/0x70 [<c0123b6f>] finish_task_switch+0x2b/0x84 [<c0299877>] schedule+0x66d/0x6e7 [<c0104710>] xen_force_evtchn_callback+0xc/0x10 [<c0104710>] xen_force_evtchn_callback+0xc/0x10 [<c012a642>] local_bh_enable+0x36/0x84 [<c022f9a7>] sk_filter+0x57/0x5c [<c0233dae>] netlink_broadcast+0x1d5/0x315 [<c01c6371>] kobject_uevent_env+0x28d/0x331 [<c01e7ead>] device_del+0x10f/0x120 [<c01e7ec6>] device_unregister+0x8/0x10 [<c015f86d>] bdi_unregister+0x2d/0x39 [<c01bf6f4>] unlink_gendisk+0x23/0x3e [<c01ac946>] del_gendisk+0x7b/0xe7 [<d0828c19>] blkfront_closing+0x28/0x6e [xen_blkfront] [<d082900c>] backend_changed+0x3ad/0x41d [xen_blkfront] We can fix this by calling del_gendisk() later in blkfront_closing, after releasing blkif_io_lock. Since the queue is stopped during the interrupts disabled phase I don't think there is any danger of an event occuring between releasing the blkif_io_lock and deleting the disk. Signed-off-by: NIan Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
由 Ian Campbell 提交于
This situation can occur when attempting to attach a block device whose backend is an empty physical CD-ROM driver. The backend in this case will go directly from the Initialising state to Closing->Closed. Previously this would result in a NULL pointer deref on info->gd (xenbus_dev_fatal does not return as a1a15ac5 seems to expect) Cc: stable@kernel.org Signed-off-by: NIan Campbell <ian.campbell@citrix.com> Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
由 Ajit Khaparde 提交于
Signed-off-by: NAjit Khaparde <ajitk@serverengines.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 18 5月, 2009 8 次提交
-
-
由 David Woodhouse 提交于
Commit c45d6320 ("fix reference counting of ftdi_private") stopped ftdi_sio_port_remove() from directly freeing the port-private data, with the intention if the port was still open, it would be freed when ftdi_close() is eventually called and releases the last refcount on the structure. That's all very well, but ftdi_sio_port_remove() still contains a call to usb_set_serial_port_data(port, NULL) -- so by the time we get to ftdi_close() for the port which was unplugged, it _still_ oopses on dereferencing that NULL pointer, as it did before (and does in 2.6.29). The fix is just not to clear the private data in ftdi_sio_port_remove(). Then the refcount is properly reduced to zero when the final kref_put() happens in ftdi_close(). Remove a bogus comment too, while we're at it. And stop doing things inside "if (priv)" -- it must _always_ be there. Based loosely on an earlier patch by Daniel Mack, and suggestions by Alan Stern. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Tested-by: NDaniel Mack <daniel@caiaq.de> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Peter Korsgaard 提交于
Commit 5b7f3a50 (fix dataflash 64-bit divisions) unfortunately introduced a typo. Erase addr and len were swapped in the pageaddr calculation, causing the wrong sectors to get erased. Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk> Acked-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Mike Frysinger 提交于
The remove function uses __devexit, so the .remove assignment needs __devexit_p() to fix a build error with hotplug disabled. Signed-off-by: NMike Frysinger <vapier@gentoo.org> CC: Liam Girdwood <lrg@slimlogic.co.uk> CC: Mike Rapoport <mike@compulab.co.il> CC: Eric Miao <eric.miao@marvell.com> Acked-by: NEric Miao <eric.y.miao@gmail.com> Signed-off-by: NLiam Girdwood <lrg@slimlogic.co.uk>
-
由 roel kluin 提交于
FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NRam Vepa <ram.vepa@neterion.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Gabriel Paubert 提交于
After 2.6.29, PPC no more admits passing NULL to the dev parameter of the DMA API. The result is a BUG followed by solid lock-up when the mv643xx_eth driver brings an interface up. The following patch makes the driver work on my Pegasos again; it is mostly a search and replace of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping functions. Signed-off-by: NGabriel Paubert <paubert@iram.es> Acked-by: NLennert Buytenhek <buytenh@marvell.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stephen Hemminger 提交于
One of the purposes of bonding is to allow for redundant links, and failover correctly if the cable is pulled. If all the members of a bonded device have no carrier present, the bonded device itself needs to report no carrier present to user space so management tools (like routing daemons) can respond. Bonding in 802.3ad mode does not work correctly for this because it incorrectly chooses a link that is down as a possible aggregator. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NJay Vosburgh <fubar@us.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ralf Baechle 提交于
Mixing of normal and irq spinlocks results in the following lockdep messages on bootup on IP32: [...] Sending DHCP requests . ====================================================== [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] 2.6.30-rc5-00164-g41baeef #30 ------------------------------------------------------ swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire: (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c and this task is already holding: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c which would create a new lock dependency: (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...} but this new dependency connects a SOFTIRQ-irq-safe lock: (_xmit_ETHER#2){+.-...} ... which became SOFTIRQ-irq-safe at: [<ffffffff80061458>] __lock_acquire+0x784/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 to a SOFTIRQ-irq-unsafe lock: (&priv->meth_lock){+.+...} ... which became SOFTIRQ-irq-unsafe at: ... [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 other info that might help us debug this: 2 locks held by swapper/1: #0: (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0 #1: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c the SOFTIRQ-irq-safe lock's dependencies: -> (_xmit_ETHER#2){+.-...} ops: 0 { HARDIRQ-ON-W at: [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 IN-SOFTIRQ-W at: [<ffffffff80061458>] __lock_acquire+0x784/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 INITIAL USE at: [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 } ... key at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8 the SOFTIRQ-irq-unsafe lock's dependencies: -> (&priv->meth_lock){+.+...} ops: 0 { HARDIRQ-ON-W at: [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 SOFTIRQ-ON-W at: [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 INITIAL USE at: [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 } ... key at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8 stack backtrace: Call Trace: [<ffffffff8000ed0c>] dump_stack+0x8/0x34 [<ffffffff80060b74>] check_usage+0x470/0x4a0 [<ffffffff80060c34>] check_irq_usage+0x90/0x130 [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84 [<ffffffff8026388c>] meth_tx+0x48/0x43c [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0 [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 ..... timed out! IP-Config: Retrying forever (NFS root)... Sending DHCP requests ., OK [...] Fixed by converting all locks to irq locks. Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Tested-by: NAndrew Randrianasulu <randrik_a@yahoo.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yevgeny Petrilin 提交于
Napi structures are being created each time we open a port, but when the port is closed the napi structure is only disabled but not removed. This bug caused hang while removing the driver. Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 5月, 2009 3 次提交
-
-
由 Alan Cox 提交于
The Sony TZ90 needs the cable type hardcoding. See bug #12734 Signed-off-by: NAlan Cox <alan@linux.intel.com> Reported-by: NJonathan E. Snow <jesnow@uh.edu> [bart: port it from ata_piix to piix and give reporter the proper credit] Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
由 Sergei Shtylyov 提交于
The second IDE channel of version 6 PCB is not being registered anymore since the commit 48c3c107 (ide: add struct ide_host (take 3)). Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
由 Tejun Heo 提交于
Impact: fix an oops which always triggers ide_tape_issue_pc() assumed drive->pc isn't NULL on invocation when checking for back-to-back request sense issues but drive->pc can be NULL and even when it's not NULL, it's not safe to dereference it once the previous command is complete because pc could have been freed or was on stack. Kill back-to-back REQUEST_SENSE detection. Signed-off-by: NTejun Heo <tj@kernel.org> Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
-
- 16 5月, 2009 14 次提交
-
-
由 Tony Lindgren 提交于
This makes the framebuffer work on omap3. Also fix the clk_get usage for checkpatch.pl "ERROR: do not use assignment in if condition". Cc: Imre Deak <imre.deak@nokia.com> Cc: linux-fbdev-devel@lists.sourceforge.net Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Len Brown 提交于
Processor idle power states C2 and C3 stop the TSC on many machines. Linux recognizes this situation and marks the TSC as unstable: Marking TSC unstable due to TSC halts in idle But if those same machines are booted with "processor.max_cstate=1", then there is no need to validate C2 and C3, and no need to disable the TSC, which can be reliably used as a clocksource. Signed-off-by: NLen Brown <len.brown@intel.com> Acked-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Len Brown 提交于
A previous 2.6.30 patch, a71e4917, (ACPI: idle: mark_tsc_unstable() at init-time, not run-time) erroneously disabled the TSC on systems that did not actually have valid deep C-states. Move the check after the deep-C-states are validated, via new helper, tsc_check_state(), hich replaces tsc_halts_in_c(). Signed-off-by: NLen Brown <len.brown@intel.com> Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NFrans Pop <elendil@planet.nl>
-
由 Zhang Rui 提交于
If the BIOS hands us an invalid throttling state, write a valid state. http://bugzilla.kernel.org/show_bug.cgi?id=13259Signed-off-by: NZhang Rui <rui.zhang@intel.com> Tested-by: NJames Ettle <theholyettlz@googlemail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Introduce module parameter processor.ignore_tpc. Some laptops are shipped with buggy _TPC, this module parameter is used to to disable the buggy support. http://bugzilla.kernel.org/show_bug.cgi?id=13259Signed-off-by: NZhang Rui <rui.zhang@intel.com> Tested-by: NJames Ettle <theholyettlz@googlemail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
drivers/built-in.o: In function `intel_opregion_init': (.text+0x9d540): undefined reference to `acpi_video_register' http://bugzilla.kernel.org/show_bug.cgi?id=13165Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
In 2.6.29, 31878dd8 "ACPI: remove BM_RLD access from idle entry path" moved BM_RLD initialization to init-time from run time. But we discovered that some BIOS do not restore BM_RLD after suspend, causing device errors on C3 and C4 after resume. So now the kernel restores BM_RLD. http://bugzilla.kernel.org/show_bug.cgi?id=13032Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit. (The BIOS is supposed to update SCI_EN, not the OS) http://bugzilla.kernel.org/show_bug.cgi?id=13289Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Martin K. Petersen 提交于
This patch provides new heuristics for parsing both the form factor and media rotation rate ATA IDENFITY words. The reported ATA version must be 7 or greater and the device must return values defined as valid in the standard. Only then are the characteristics reported to SCSI via the VPD B1 page. This seems like a reasonable compromise to me considering that we have been shipping several kernel releases that key off the rotation rate bit without any version checking whatsoever. With no complaints so far. Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Martin K. Petersen 提交于
For disks with 4KB sectors, report the correct block size and alignment when filling out the READ CAPACITY(16) response. This patch is based upon code from Matthew Wilcox' 4KB ATA tree. I fixed the bug I reported a while back caused by ATA and SCSI using different approaches to describing the alignment. Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Dave Liu 提交于
The bit 11 of command description is reserved bit in Freescale SATA controller and needs to be set to '1'. This is needed to make sure the last write from the controller to the buffer descriptor is seen before an interrupt is raised. Signed-off-by: NDave Liu <daveliu@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Kumar Gala 提交于
We we build with dma_addr_t as a 64-bit quantity we get: drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg': drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'dma_addr_t' Signed-off-by: NKumar Gala <galak@kernel.crashing.org> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 David Milburn 提交于
Issuing ATA_CMD_SET_FEATURES (0xef) times out because pdc20621_interrupt ignores command completion since ATA_TFLAG_POLLING flag is set. This has already been fixed for sata_promise: commit 51b94d2a Author: Tejun Heo <htejun@gmail.com> Date: Fri Jun 8 13:46:55 2007 -0700 sata_promise: use TF interface for polling NODATA commands Also, this patch includes Mikael's original patches: http://marc.info/?l=linux-ide&m=121135828227724&w=2 http://marc.info/?l=linux-ide&m=121144512109826&w=2Signed-off-by: NMikael Pettersson <mikpe@it.uu.se> Signed-off-by: NDavid Milburn <dmilburn@redhat.com> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Jeff Garzik 提交于
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
- 15 5月, 2009 1 次提交
-
-
由 Jason Wessel 提交于
Commit 79e53945 introduced a regression where you cannot use sysrq 'g' to enter kgdb. The solution is to move the intel fb sysrq over to V for video instead of G for graphics. The SMP VOYAGER code to register for the sysrq-v is not anywhere to be found in the mainline kernel, so the comments in the code were cleaned up as well. This patch also cleans up the sysrq definitions for kgdb to make it generic for the kernel debugger, such that the sysrq 'g' can be used in the future to enter a gdbstub or another kernel debugger. Signed-off-by: NJason Wessel <jason.wessel@windriver.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Acked-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-