| Age | Commit message (Collapse) | Author |
|---|
|
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(re-send with updated changelog)
cpufreq fix timer teardown in conservative governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
The patches linked above depend on the following patch to remove
circular locking dependency :
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).
* KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
> Hi
>
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
>
> A: work -> do_dbs_timer() -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
>
>
Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.
The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().
Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :
cpufreq.c: __cpufreq_remove_dev()
...
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
unlock_policy_rwsem_write(cpu);
To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.
Applies on top of the 2.6.30-rc5 tree.
Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
|
|
We shouldn't hold dpm_list_mtx while executing
[disable|enable]_nonboot_cpus(), because theoretically this may lead
to a deadlock as shown by the following example (provided by Johannes
Berg):
CPU 3 CPU 2 CPU 1
suspend/hibernate
something:
rtnl_lock() device_pm_lock()
-> mutex_lock(&dpm_list_mtx)
mutex_lock(&dpm_list_mtx)
linkwatch_work
-> rtnl_lock()
disable_nonboot_cpus()
-> flush CPU 3 workqueue
Fortunately, device drivers are supposed to stop any activities that
might lead to the registration of new device objects way before
disable_nonboot_cpus() is called, so it shouldn't be necessary to
hold dpm_list_mtx over the entire late part of device suspend and
early part of device resume.
Thus, during the late suspend and the early resume of devices acquire
dpm_list_mtx only when dpm_list is going to be traversed and release
it right after that.
This patch is reported to fix the regressions tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=13245.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Miles Lane <miles.lane@gmail.com>
Tested-by: Ming Lei <tom.leiming@gmail.com>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] mpt2sas: fix driver version inconsistency
[SCSI] 3w-xxxx: scsi_dma_unmap fix
[SCSI] 3w-9xxx: scsi_dma_unmap fix
[SCSI] ses: fix problems caused by empty SES provided name
[SCSI] fc-transport: Close state transition-window during rport deletion.
[SCSI] initialize max_target_blocked in scsi_alloc_target
[SCSI] fnic: Add new Cisco PCI-Express FCoE HBA
|
|
Actually the icom driver is crashing when is being removed because
the driver is kfreeing the adapter structure before calling
pci_release_regions(), which result in the following error:
Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d33
Faulting instruction address: 0xc000000000246b80
Oops: Kernel access of bad area, sig: 11 [#1]
....
[c000000012d436a0] [c0000000001002d0] .kfree+0x120/0x34c (unreliable)
[c000000012d43730] [c000000000246d60] .pci_release_selected_regions+0x3c/0x68
[c000000012d437c0] [d000000002d54700] .icom_kref_release+0xf4/0x118 [icom]
[c000000012d43850] [c000000000232e50] .kref_put+0x74/0x94
[c000000012d438d0] [d000000002d56c58] .icom_remove+0x40/0xa4 [icom]
[c000000012d43960] [c000000000249e48] .pci_device_remove+0x50/0x90
[c000000012d439e0] [c0000000002d68d8] .__device_release_driver+0x94/0xd4
[c000000012d43a70] [c0000000002d7104] .driver_detach+0xf8/0x12c
[c000000012d43b00] [c0000000002d549c] .bus_remove_driver+0xbc/0x11c
[c000000012d43b90] [c0000000002d71dc] .driver_unregister+0x60/0x80
[c000000012d43c20] [c00000000024a07c] .pci_unregister_driver+0x44/0xe8
[c000000012d43cb0] [d000000002d56bf4] .icom_exit+0x1c/0x40 [icom]
[c000000012d43d30] [c000000000095fa8] .SyS_delete_module+0x214/0x2a8
[c000000012d43e30] [c00000000000852c] syscall_exit+0x0/0x40
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Cc: stable@kernel.org
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
via82cxxx: Add VIA VX855 PCI Device ID
ide: report timeouts in ide_busy_sleep()
ide: improve failed opcode reporting
ide: fix printk() levels in ide_dump_ata[pi]_error()
ide: fix OOPS during ide-cd error recovery
ide: fix 40-wire cable detection for TSST SH-S202* ATAPI devices (v2)
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6
* 'sh/for-2.6.30' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
video: stop sh_mobile_lcdcfb only if started
sh: ap325 camera without i2c driver fix
|
|
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: Corey Minyard <cminyard@mvista.com>
Cc: Ferenc Wagner <wferi@niif.hu>
Cc: Dan Frazier <dannf@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This patch adds the PCI Device ID 0xc409 to the PCI ID table of via82cxxx.c,
as well as the 0x8409 south bridge ID.
This is required to make the IDE driver work on the VX855/VX875 integrated
chipset.
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Bruce Chang <BruceChang@via.com.tw>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
* change 'hwif' argument to 'drive'
* report an error on timeout
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
Nowadays we (almost) always store the currently executing command
in hwif->cmd so we can use it for the failed opcode reporting.
Cc: Martin Lottermoser <Martin.Lottermoser@t-online.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
Fixes "<3>" in error messages like this one:
hdc: cdrom_decode_status: error=0x40 <3>{ LastFailedSense=0x04 }
Reported-by: Martin Lottermoser <Martin.Lottermoser@t-online.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
On Tuesday 19 May 2009 20:29:28 Martin Lottermoser wrote:
> hdc: cdrom_decode_status: error=0x40 <3>{ LastFailedSense=0x04 }
> ide: failed opcode was: unknown
> hdc: DMA disabled
> ------------[ cut here ]------------
> kernel BUG at drivers/ide/ide-io.c:872!
It is possible for ide-cd to ignore ide_error()'s return value under
some circumstances. Workaround it in ide_intr() and ide_timer_expiry()
by checking if there is a device/port reset pending currently.
Fixes bug #13345:
http://bugzilla.kernel.org/show_bug.cgi?id=13345
Reported-by: Martin Lottermoser <Martin.Lottermoser@t-online.de>
Reported-and-tested-by: Modestas Vainius <modestas@vainius.eu>
Cc: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
Since 2.6.26 we support UDMA66 on ATAPI devices requiring IVB quirk:
commit 8588a2b732928b343233af9b1855705b8286bed4
("ide: add SH-S202J to ivb_list[]")
We also later added support for more such devices in:
commit e97564f362a93f8c248246c19828895950341252
("ide: More TSST drives with broken cable detection")
and in:
commit 3ced5c49bd2d1f2c7f769e3a54385883de63a652
("ide: add TSSTcorp CDDVDW SH-S202H to ivb_list[]")
It turns out that such devices lack cable detection altogether
(which in turn results in incorrect detection of 40-wire cables
by our current cable detection strategy) so always handle them
by trusting host-side cable detection only.
v2:
Model detection fixup from Martin.
Reported-and-tested-by: Martin Lottermoser <Martin.Lottermoser@t-online.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
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: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI PM: Fix initialization and kexec breakage for some devices
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-2.6:
drm: Copy back ioctl data to userspace regardless of return code.
drm: Round size of SHM maps to PAGE_SIZE
|
|
* master.kernel.org:/home/rmk/linux-2.6-arm: (25 commits)
[ARM] 5519/1: amba probe: pass "struct amba_id *" instead of void *
[ARM] 5517/1: integrator: don't put clock lookups in __initdata
[ARM] 5518/1: versatile: don't put clock lookups in __initdata
[ARM] mach-l7200: fix spelling of SYS_CLOCK_OFF
[ARM] Double check memmap is actually valid with a memmap has unexpected holes V2
[ARM] realview: fix broadcast tick support
[ARM] realview: remove useless smp_cross_call_done()
[ARM] smp: fix cpumask usage in ARM SMP code
[ARM] 5513/1: Eurotech VIPER SBC: fix compilation error
[ARM] 5509/1: ep93xx: clkdev enable UARTS
ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi, v2
ARM: OMAP3: Fix HW SAVEANDRESTORE shift define
ARM: OMAP3: Fix number of GPIO lines for 34xx
[ARM] S3C: Do not set clk->owner field if unset
[ARM] S3C2410: mach-bast.c registering i2c data too early
[ARM] S3C24XX: Fix unused code warning in arch/arm/plat-s3c24xx/dma.c
[ARM] S3C64XX: fix GPIO debug
[ARM] S3C64XX: GPIO include cleanup
[ARM] nwfpe: fix 'floatx80_is_nan' sparse warning
[ARM] nwfpe: Add decleration for ExtendedCPDO
...
|
|
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: Alessandro Rubini <rubini@unipv.it>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Fixes a regression from commit 9d5b3ffc42f7820e8ee07705496955e4c2c38dd9
('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: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
cdrom: beyond ARRAY_SIZE of viocd_diskinfo
xen/blkfront: fix warning when deleting gendisk on unplug/shutdown
xen/blkfront: allow xenbus state transition to Closing->Closed when not Connected
|
|
Do not go beyond ARRAY_SIZE of viocd_diskinfo
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
mfd: pcf50633: fix unsafe disable_irq()
mfd: Keep a cache of WM8350 volatile values
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
ipv4: make default for INET_LRO consistent with help text
net: fix skb_seq_read returning wrong offset/length for page frag data
pkt_sched: gen_estimator: use 64 bit intermediate counters for bps
be2net: add two new pci device ids to pci device table
sch_teql: should not dereference skb after ndo_start_xmit()
tcp: fix MSG_PEEK race check
Doc: fixed descriptions on /proc/sys/net/core/* and /proc/sys/net/unix/*
Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR?
mv643xx_eth: fix PPC DMA breakage
bonding: fix link down handling in 802.3ad mode
bridge: fix initial packet flood if !STP
bridge: relay bridge multicast pkgs if !STP
NET: Meth: Fix unsafe mix of irq and non-irq spinlocks.
mlx4_en: Fix not deleted napi structures
ipconfig: handle case of delayed DHCP server
netpoll: don't dereference NULL dev from np
wimax/i2400m: fix device crash: fix optimization in _roq_queue_update_ws
|
|
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: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
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: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
|
|
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: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
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 3aa551c9b4c40018f0e261a178e3d25478dc04a9
: 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: Nelson Castillo <arhuaco@freaks-unidos.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <balajirrao@openmoko.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
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: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
regulator: da903x: add missing __devexit_p()
|
|
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: Martin Knoblauch <spamtrap@knobisoft.de>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Connected
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: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In Commit
commit 3b8b5c9b1f08660583e5dfe095c24170df62f1d2
Author: Eric Moore <eric.moore@lsi.com>
Date: Tue Apr 21 15:44:27 2009 -0600
[SCSI] mpt2sas : bump driver version to 01.100.02.00
The MPT2SAS_MAJOR_VERSION didn't get bumped from 00 to 01 so
applications will see it incorrectly as 00.100.02.00 driver instead of
01.100.02.00. Fix by making MPT2SAS_MAJOR_VERSION match the major
number in MPT2SAS_DRIVER_VERSION
Signed-off-by: Eric Moore <eric.moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
|
|
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: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Daniel Mack <daniel@caiaq.de>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike 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: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
|
|
FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Ram Vepa <ram.vepa@neterion.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
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: Gabriel Paubert <paubert@iram.es>
Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
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: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
|
|
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: Ralf Baechle <ralf@linux-mips.org>
Tested-by: Andrew Randrianasulu <randrik_a@yahoo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
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: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: padlock - Revert aes-all alias to aes
crypto: api - Fix algorithm module auto-loading
crypto: eseqiv - Fix IV generation for sync algorithms
crypto: ixp4xx - check firmware for crypto support
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
piix: The Sony TZ90 needs the cable type hardcoding
icside: register second channel of version 6 PCB
ide-tape: remove back-to-back REQUEST_SENSE detection
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: Idle C-states disabled by max_cstate should not disable the TSC
ACPI: idle: fix init-time TSC check regression
ACPI processor: reset the throttling state once it's invalid
ACPI processor: introduce module parameter processor.ignore_tpc
ACPI, i915: build fix
ACPI: suspend: restore BM_RLD on resume
ACPI: resume: re-enable SCI-enable workaround
thermal: fix off-by-1 error in trip point trigger condition
eeepc-laptop: unregister_rfkill_notifier on failure
asus-laptop: fix input keycode
eeepc-laptop: support for super hybrid engine (SHE)
eeepc-laptop: Work around rfkill firmware bug
eeepc-laptop: report brightness control events via the input layer
eeepc-laptop: fix wlan rfkill state change during init
ACPI: suspend: don't let device _PS3 failure prevent suspend
ACPI: power: update error message
ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness
ACPICA: use acpi.* modparam namespace
ACPI video: dmi check for broken _BQC on Acer Aspire 5720
|
|
The Sony TZ90 needs the cable type hardcoding. See bug #12734
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Jonathan E. Snow <jesnow@uh.edu>
[bart: port it from ata_piix to piix and give reporter the proper credit]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
