CMD646 corrupts data on concurrent transfers on both channels when IDE SSD is
connected to one of the channels.
Setup that demonstrates this hardware bug: Ultra 5, onboard CMD646, rev 3.
/dev/hda is 8GB Seagate ST38410A in MWDMA2
/dev/hdd is 32GB SSD SiliconHardDisk in MWDMA2
- When reading /dev/hdd (for example with dd or fsck), reads from /dev/hda
are corrupted, there are twiddled single bits 1->0 and some full 32-bit
words corrupted, sometimes commands fail (which switches /dev/hda to
PIO mode but the corruptions happen even in PIO).
- Reads from /dev/hdd don't seem to be corrupted (i.e. fsck passes fine).
- When I connected normal rotating harddisk to /dev/hdd, there was no
corruption, so the corruption is something specific to SSD.
- I tried the same setup on a PCI card with CMD649 and saw no corruption.
This patch serializes the operation for CMD646 and 643 (I didn't test
CMD643 but it may have the same hw bug too because it's earlier design).
CMD649 is good. I don't know anything about CMD 648.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Tested-by: Frans Pop <elendil@planet.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
I found that the current version of drivers/net/usb/dm9601.c can be used to
successfully drive a low-power, low-cost network adapter with USB ID
0a46:9000, based on a DM9000E chipset. As no device with this ID is yet
present in the kernel, I have created a patch that adds support for the device
to the dm9601 driver.
Created and tested against linux-2.6.32-rc5.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mailbox command process would only process a maximum of 5 unrelated
firmware events while waiting for it's command completion status.
It should process an unlimited number of events while waiting for a maximum of 5 seconds.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clean up driver resources without touch the hardware. Add pci
save/restore state.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Augment raw_send_hdrinc to correct for incorrect ip header length values
A series of oopses was reported to me recently. Apparently when using AF_RAW
sockets to send data to peers that were reachable via ipsec encapsulation,
people could panic or BUG halt their systems.
I've tracked the problem down to user space sending an invalid ip header over an
AF_RAW socket with IP_HDRINCL set to 1.
Basically what happens is that userspace sends down an ip frame that includes
only the header (no data), but sets the ip header ihl value to a large number,
one that is larger than the total amount of data passed to the sendmsg call. In
raw_send_hdrincl, we allocate an skb based on the size of the data in the msghdr
that was passed in, but assume the data is all valid. Later during ipsec
encapsulation, xfrm4_tranport_output moves the entire frame back in the skbuff
to provide headroom for the ipsec headers. During this operation, the
skb->transport_header is repointed to a spot computed by
skb->network_header + the ip header length (ihl). Since so little data was
passed in relative to the value of ihl provided by the raw socket, we point
transport header to an unknown location, resulting in various crashes.
This fix for this is pretty straightforward, simply validate the value of of
iph->ihl when sending over a raw socket. If (iph->ihl*4U) > user data buffer
size, drop the frame and return -EINVAL. I just confirmed this fixes the
reported crashes.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In mii monitor mode, bond_check_dev_link() calls the the ioctl
handler of slave devices. It stores the ndo_do_ioctl function
pointer to a static (!) ioctl variable and later uses it to call the
handler with the IOCTL macro.
If another thread executes bond_check_dev_link() at the same time
(even with a different bond, which none of the locks prevent), a
race condition occurs. If the two racing slaves have different
drivers, this may result in one driver's ioctl handler being
called with a pointer to a net_device controlled with a different
driver, resulting in unpredictable breakage.
Unless I am overlooking something, the "static" must be a
copy'n'paste error (?).
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
We create a dummy struct kernel_param on the stack for parsing each
array element, but we didn't initialize the flags word. This matters
for arrays of type "bool", where the flag indicates if it really is
an array of bools or unsigned int (old-style).
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
kp->arg is always true: it's the contents of that pointer we care about.
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
e180a6b775 "param: fix charp parameters set via sysfs" fixed the case
where charp parameters written via sysfs were freed, leaving drivers
accessing random memory.
Unfortunately, storing a flag in the kparam struct was a bad idea: it's
rodata so setting it causes an oops on some archs. But that's not all:
1) module_param_array() on charp doesn't work reliably, since we use an
uninitialized temporary struct kernel_param.
2) there's a fundamental race if a module uses this parameter and then
it's changed: they will still access the old, freed, memory.
The simplest fix (ie. for 2.6.32) is to never free the memory. This
prevents all these problems, at cost of a memory leak. In practice, there
are only 18 places where a charp is writable via sysfs, and all are
root-only writable.
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: Sitsofe Wheeler <sitsofe@yahoo.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Christof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
On SMP guests, reads from the ring might bypass used index reads. This
causes guest crashes because host writes to used index to signal ring
data readiness. Fix this by inserting rmb before used ring reads.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
Commit f68d24082e
in 2.6.32-rc1 broke requesting IRQs for per-VQ MSI-X vectors:
- vector number was used instead of the vector itself
- we try to request an IRQ for VQ which does not
have a callback handler
This is a regression that causes warnings in kernel log,
potentially lower performance as we need to scan vq list,
and might cause system failure if the interrupt
requested is in fact needed by another system.
This was not noticed earlier because in most cases
we were falling back on shared interrupt for all vqs.
The warnings often look like this:
virtio-pci 0000:00:03.0: irq 26 for MSI/MSI-X
virtio-pci 0000:00:03.0: irq 27 for MSI/MSI-X
virtio-pci 0000:00:03.0: irq 28 for MSI/MSI-X
IRQ handler type mismatch for IRQ 1
current handler: i8042
Pid: 2400, comm: modprobe Tainted: G W
2.6.32-rc3-11952-gf3ed8d8-dirty #1
Call Trace:
[<ffffffff81072aed>] ? __setup_irq+0x299/0x304
[<ffffffff81072ff3>] ? request_threaded_irq+0x144/0x1c1
[<ffffffff813455af>] ? vring_interrupt+0x0/0x30
[<ffffffff81346598>] ? vp_try_to_find_vqs+0x583/0x5c7
[<ffffffffa0015188>] ? skb_recv_done+0x0/0x34 [virtio_net]
[<ffffffff81346609>] ? vp_find_vqs+0x2d/0x83
[<ffffffff81345d00>] ? vp_get+0x3c/0x4e
[<ffffffffa0016373>] ? virtnet_probe+0x2f1/0x428 [virtio_net]
[<ffffffffa0015188>] ? skb_recv_done+0x0/0x34 [virtio_net]
[<ffffffffa00150d8>] ? skb_xmit_done+0x0/0x39 [virtio_net]
[<ffffffff8110ab92>] ? sysfs_do_create_link+0xcb/0x116
[<ffffffff81345cc2>] ? vp_get_status+0x14/0x16
[<ffffffff81345464>] ? virtio_dev_probe+0xa9/0xc8
[<ffffffff8122b11c>] ? driver_probe_device+0x8d/0x128
[<ffffffff8122b206>] ? __driver_attach+0x4f/0x6f
[<ffffffff8122b1b7>] ? __driver_attach+0x0/0x6f
[<ffffffff8122a9f9>] ? bus_for_each_dev+0x43/0x74
[<ffffffff8122a374>] ? bus_add_driver+0xea/0x22d
[<ffffffff8122b4a3>] ? driver_register+0xa7/0x111
[<ffffffffa001a000>] ? init+0x0/0xc [virtio_net]
[<ffffffff81009051>] ? do_one_initcall+0x50/0x148
[<ffffffff8106e117>] ? sys_init_module+0xc5/0x21a
[<ffffffff8100af02>] ? system_call_fastpath+0x16/0x1b
virtio-pci 0000:00:03.0: irq 26 for MSI/MSI-X
virtio-pci 0000:00:03.0: irq 27 for MSI/MSI-X
Reported-by: Marcelo Tosatti <mtosatti@redhat.com>
Reported-by: Shirley Ma <xma@us.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The requeue_pi path doesn't use unqueue_me() (and the racy lock_ptr ==
NULL test) nor does it use the wake_list of futex_wake() which where
the reason for commit 41890f2 (futex: Handle spurious wake up)
See debugging discussing on LKML Message-ID: <4AD4080C.20703@us.ibm.com>
The changes in this fix to the wait_requeue_pi path were considered to
be a likely unecessary, but harmless safety net. But it turns out that
due to the fact that for unknown $@#!*( reasons EWOULDBLOCK is defined
as EAGAIN we built an endless loop in the code path which returns
correctly EWOULDBLOCK.
Spurious wakeups in wait_requeue_pi code path are unlikely so we do
the easy solution and return EWOULDBLOCK^WEAGAIN to user space and let
it deal with the spurious wakeup.
Cc: Darren Hart <dvhltc@us.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: John Stultz <johnstul@linux.vnet.ibm.com>
Cc: Dinakar Guniguntala <dino@in.ibm.com>
LKML-Reference: <4AE23C74.1090502@us.ibm.com>
Cc: stable@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Fix sparse warning in arch/arm/mach-s3c2410/gpio.c due to missing
include of <mach/gpio-fns.h>. Fixes the following warning:
warning: symbol 's3c2410_gpio_irqfilter' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix the following sparse warnings in arch/arm/mach-s3c2440/mach-mini2440.c
due to missing 'static'.
warning: symbol 'mini2440_lcd_cfg' was not declared. Should it be static?
warning: symbol 'mini2440_fb_info' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix the following warnings from sparse in arch/arm/plat-s3c24xx/gpio.
due to the missing include of <mach/gpio-fns.h>
gpio.c:36:6: warning: symbol 's3c2410_gpio_cfgpin' was not declared. Should it be static?
gpio.c:84:14: warning: symbol 's3c2410_gpio_getcfg' was not declared. Should it be static?
gpio.c:103:6: warning: symbol 's3c2410_gpio_pullup' was not declared. Should it be static?
gpio.c:125:5: warning: symbol 's3c2410_gpio_getpull' was not declared. Should it be static?
gpio.c:138:6: warning: symbol 's3c2410_gpio_setpin' was not declared. Should it be static?
gpio.c:157:14: warning: symbol 's3c2410_gpio_getpin' was not declared. Should it be static?
gpio.c:184:5: warning: symbol 's3c2410_gpio_getirq' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix missing select of S3C_DEV_USB_HOST when building for mini2440
only. Fixes the following error:
built-in.o: undefined reference to `s3c_device_usb`
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
If the NULL test on buf is needed, then the dereference should be after the
NULL test.
A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):
// <smpl>
@match exists@
expression x, E;
identifier fld;
@@
* x->fld
... when != \(x = E\|&x\)
* x == NULL
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix the export of s3c_adc_read.
Signed-off-by: Ryan Mallon <ryan@bluewatersys.com>
[ben-linux@fluff.org: remove unexport of s3c_adc_start, needed for ts]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix the link errors if cpu-frequency support is enabled on s3c2410 systems
but there is no CONFIG_S3C2410_IOTIMING set. Fix this by ensuring the
relevant symbols are defined NULL if the code is not being built in.
Fixes the following error:
arch/arm/mach-s3c2410/built-in.o: undefined reference to `s3c2410_iotiming_get'
arch/arm/mach-s3c2410/built-in.o: undefined reference to `s3c2410_iotiming_set'
arch/arm/mach-s3c2410/built-in.o: undefined reference to `s3c2410_iotiming_calc'
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add the S3C2442B CPU ID to aid support the Openmoko GTA02 / Freerunner.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
Signed-off-by: Andy Green <andy@warmcat.com>
Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
[ben-linux@fluff.org: edit description for clarity and S3C2442B as uppercase]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Define a macro to avoid the following error during kernel build process
for platforms other than s3c2410:
arch/arm/plat-s3c24xx/cpu.c:84: error: ‘s3c2410a_init’ undeclared here (not in a function)
Signed-off-by: Ramax Lo <ramaxlo@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
The S3C64XX DMA implementation will work a lot better with the ability
to enqueue circular buffers as the hardware can do it's own linked-list
management.
Add a function s3c_dma_has_circular() to show that the system can do this
and a flag for the channel.
Update the s3c24xx/s3c64xx I2S DMA code to deal with this.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Acked-by: Mark Brown <broonie@@opensource.wolfsonmicro.com>
pcpu_alloc() and pcpu_extend_area_map() perform a series of
spin_lock_irq()/spin_unlock_irq() calls, which make them unsafe
with respect to being called from contexts which have IRQs off.
This patch converts the code to perform save/restore of flags instead,
making pcpu_alloc() (or __alloc_percpu() respectively) to be called
from early kernel startup stage, where IRQs are off.
This is needed for proper initialization of per-cpu rq_weight data from
sched_init().
tj: added comment explaining why irqsave/restore is used in alloc path.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Tejun Heo <tj@kernel.org>
virtio net used to unlink skbs from send queues on error,
but ever since 48925e372f
we do not do this. This causes guest data corruption and crashes
with vhost since net core can requeue the skb or free it without
it being taken off the list.
This patch fixes this by queueing the skb after successful
transmit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Page buffers containing packets with an incorrect checksum or using a
protocol not handled by hardware checksum offload were previously not
passed to LRO. The conversion to GRO changed this, but did not set
the ip_summed value accordingly.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The BNX2_L2CTX_STATUSB_NUM definition needs to be changed to match
the recent firmware update:
commit 078b073588
bnx2: Update firmware to 5.0.0.j3.
Without the fix, bnx2 can crash intermittently in bnx2_rx_int() when
iSCSI is enabled.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This sets the fbcon to use TRUECOLOR by default, it then
only modifies the pseudo palette for fbcon, and only touches
the real palette when in 8-bit pseudo color mode.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sometimes we will get the incorrect display modeline when parsing the detailed
timing in EDID. For example:
>hsync/vsync width is zero
>sync is beyond the blank.
So add the basic check for the detailed timing in EDID to avoid the incorrect
display modeline.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since we register all radeon devices, and the arbiter only cares about
VGA class ones, we will fail to startup on display controller class devices.
We don't gain anything by using the return value here.
this helps kms on sparc64 get started.
Reported-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
xen_setup_stackprotector() ends up trying to set page protections,
so we need to have vm_mmu_ops set up before trying to do so.
Failing to do so causes an early boot crash.
[ Impact: Fix early crash under Xen. ]
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Test whether index is within bounds before reading the element
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When hostapd injects a frame, e.g. an authentication or association
response, mac80211 looks for a suitable access point virtual interface
to associate the frame with based on its source address. This makes it
possible e.g. to correctly assign sequence numbers to the frames.
A small typo in the ethernet address comparison statement caused a
failure to find a suitable ap interface. Sequence numbers on such
frames where therefore left unassigned causing some clients
(especially windows-based 11b/g clients) to reject them and fail to
authenticate or associate with the access point. This patch fixes the
typo in the address comparison statement.
Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix a typo in the description of hwmp_route_info_get(), no function
changes.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the in-kernel SME gets an association failure from
the AP we don't deauthenticate, and thus get into a very
confused state which will lead to warnings later on. Fix
this by actually deauthenticating when the AP indicates
an association failure.
(Brought to you by the hacking session at Kernel Summit 2009 in Tokyo,
Japan. -- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When association fails, we should stay authenticated,
which in mac80211 is represented by the existence of
the mlme work struct, so we cannot free that, instead
we need to just set it to idle.
(Brought to you by the hacking session at Kernel Summit 2009 in Tokyo,
Japan. -- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent commit "mac80211: fix logic error ibss merge bssid check" fixed
joining of ibss cell when static bssid is provided. In this case
ifibss->bssid is set before the cell is joined and comparing that address
to a bss should thus always succeed. Unfortunately this change broke the
other case of joining a ibss cell without providing a static bssid where
the value of ifibss->bssid is not set before the cell is joined.
Since ifibss->bssid may be set before or after joining the cell we do not
learn anything by comparing it to a known bss. Remove this check.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
'struct b43_wl' declaration is missing at 'leds.h'.
It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'.
Signed-off-by: Miguel Botón <mboton@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"b43: Fix PPC crash in rfkill polling on unload" fixed the bug reported
in Bugzilla No. 14181; however, it introduced a new bug. Whenever the
radio switch was turned off, it was necessary to unload and reload
the driver for it to recognize the switch again.
This patch fixes both the original bug in #14181 and the bug introduced by
the previous patch. It must be stated, however, that if there is a BCM4306/3
with an rfkill switch (not yet proven), then the driver will need an
unload/reload cycle to turn the device back on.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit 308cf8e13f. This
patch had trouble with transparent bridges, among other things. A more
readable and correct version should land in 2.6.33.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The EFI RTC functions are only available on 32 bit. commit 7bd867df
(x86: Move get/set_wallclock to x86_platform_ops) removed the 32bit
dependency which leads to boot crashes on 64bit EFI systems.
Add the dependency back.
Solves: http://bugzilla.kernel.org/show_bug.cgi?id=14466
Tested-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Feng Tang <feng.tang@intel.com>
LKML-Reference: <20091020125402.028d66d5@feng-desktop>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Based on an original patch by Valentine Barshak <vbarshak@ru.mvista.com>
Use preempt_schedule_irq to prevent infinite irq-entry and
eventual stack overflow problems with fast-paced IRQ sources.
This kind of problems has been observed on the PASemi Electra IDE
controller. We have to make sure we are soft-disabled before calling
preempt_schedule_irq and hard disable interrupts after that
to avoid unrecoverable exceptions.
This patch also moves the "clrrdi r9,r1,THREAD_SHIFT" out of
the #ifdef CONFIG_PPC_BOOK3E scope, since r9 is clobbered
and has to be restored in both cases.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We don't need an explicit PPC64 in the DEBUG_PREEMPT dependancies as all
PPC platforms now support TRACE_IRQFLAGS_SUPPORT.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
