Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
[PATCH] Input: ucb1400 - set up driver's name to show in sysfs
The UCB1400 is missing a name parameter in the device_driver struct.
This causes missing information in the /sys tree and seems to cause
other problems with the AC97 functionality. This was tested on a PXA270
system.
* master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6:
ide: add "optical" to sysfs "media" attribute
ide: ugly messages trying to open CD drive with no media present
ide: correctly prevent IDE timer expiry function to run if request was already handled
This happens when a "start stop unit" command (0x1b 0 0 0 3 0 0 0 0 0)
is sent to the drive to try to close the CD-ROM tray, but this drive
doesn't have that capability (it's a slim portable-type CD-ROM), so it
reports sense key 5 (illegal request) with asc/ascq 24/0. This is
exactly how SFF8090i says it should respond.
But ide-cd.c (in cdrom_decode_status() ) just sees sense key 5 and spews
out an error. It then goes on to request sense data, and
cdrom_log_sense() understands this error and doesn't log it.
The patch, for kernel 2.6.20.4, suppresses this error message.
Signed-off-by: Stuart Hayes <stuart_hayes@dell.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide: correctly prevent IDE timer expiry function to run if request was already handled
It is possible for the timer expiry function to run even though the
request has already been handled: ide_timer_expiry() only checks that
the handler is not NULL, but it is possible that we have handled a
request (thus clearing the handler) and then started a new request
(thus starting the timer again, and setting a handler).
A simple way to exhibit this is to set the DMA timeout to 1 jiffy and
run dd: The kernel will panic after a few minutes because
ide_timer_expiry() tries to add a timer when it's already active.
To fix this, we simply add a request generation count that gets
incremented at every interrupt, and check in ide_timer_expiry() that
we have not already handled a new interrupt before running the expiry
function.
David S. Miller [Mon, 9 Apr 2007 20:23:14 +0000 (13:23 -0700)]
[TCP]: slow_start_after_idle should influence cwnd validation too
For the cases that slow_start_after_idle are meant to deal
with, it is almost a certainty that the congestion window
tests will think the connection is application limited and
we'll thus decrease the cwnd there too. This defeats the
whole point of setting slow_start_after_idle to zero.
So test it there too.
We do not cancel out the entire tcp_cwnd_validate() function
so that if the sysctl is changed we still have the validation
state maintained.
Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Mon, 9 Apr 2007 18:51:15 +0000 (11:51 -0700)]
[SC92031]: Fix priv->lock context
The spin_lock calls made in dev->open and dev->close must disable
BH since open/close are made in process context. Conversely, the
call in dev->hard_start_xmit does not need to disable BH since it
is already executing with BH disabled.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Userspace uses an integer for TCA_TCINDEX_SHIFT, the kernel was changed
to expect and use a u16 value in 2.6.11, which broke compatibility on
big endian machines. Change back to use int.
Reported by Ole Reinartz <ole.reinartz@gmx.de>
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Richter [Wed, 21 Mar 2007 23:40:06 +0000 (00:40 +0100)]
ieee1394: change deprecation status of dv1394
Nobody ported ffmpeg from dv1394 to rawiso yet, and there is no
justification to remove dv1394 right now.
Nevertheless, a strong deprecation of this ABI makes a lot of sense,
especially as Kristian H's drivers shape up to be an attractive
alternative to the existing ones. But we don't have a schedule at the
moment.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Andrew Morton [Sun, 8 Apr 2007 23:04:04 +0000 (16:04 -0700)]
[PATCH] i386: irqbalance_disable() section fix
WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:irqbalance_disable from .text between 'quirk_intel_irqbalance' (at offset 0x80a5) and 'i8237A_suspend'
Andrew Morton [Sun, 8 Apr 2007 23:04:03 +0000 (16:04 -0700)]
[PATCH] x86_64 early quirks: fix early_qrk[] section tag
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:nvidia_bugs from .data between 'early_qrk' (at offset 0x8428) and 'enable_cpu_hotplug'
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:via_bugs from .data between 'early_qrk' (at offset 0x8438) and 'enable_cpu_hotplug'
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:ati_bugs from .data between 'early_qrk' (at offset 0x8448) and 'enable_cpu_hotplug'
The compiler is putting it into .data because the __initdata is in the wrong
place.
David Brownell [Sun, 8 Apr 2007 23:04:02 +0000 (16:04 -0700)]
[PATCH] omap_cf: oops-on-suspend fix
Convert omap_cf into a platform_driver ... this resolves oopsing during
suspend/resume.
Evidently folk haven't tried suspend/resume on an OSK (the main platform
for this driver) since September or so, which is when platform_device
learned about suspend_late()/resume_early() and stopped being able to
suspend/resume without a platform_driver.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] Proper fix for highmem kmap_atomic functions for VMI for 2.6.21
Since lazy MMU batching mode still allows interrupts to enter, it is
possible for interrupt handlers to try to use kmap_atomic, which fails when
lazy mode is active, since the PTE update to highmem will be delayed. The
best workaround is to issue an explicit flush in kmap_atomic_functions
case; this is the only way nested PTE updates can happen in the interrupt
handler.
Thanks to Jeremy Fitzhardinge for noting the bug and suggestions on a fix.
This patch gets reverted again when we start 2.6.22 and the bug gets fixed
differently.
Signed-off-by: Zachary Amsden <zach@vmware.com> Cc: Andi Kleen <ak@muc.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] sched: get rid of p->children use in show_task()
the p->parent PID printout gives us all the information about the
task tree that we need - the eldest_child()/older_sibling()/
younger_sibling() printouts are mostly historic and i do not
remember ever having used those fields. (IMO in fact they confuse
the SysRq-T output.) So remove them.
This code has sentimental value though, those fields and
printouts are one of the oldest ones still surviving from
Linux v0.95's kernel/sched.c:
Michael Chan [Sat, 7 Apr 2007 00:35:37 +0000 (17:35 -0700)]
[TG3]: Fix crash during tg3_init_one().
The driver will crash when the chip has been initialized by EFI before
tg3_init_one(). In this case, the driver will call tg3_chip_reset()
before allocating consistent memory.
The bug is fixed by checking for tp->hw_status before accessing it
during tg3_chip_reset().
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Thu, 5 Apr 2007 23:03:33 +0000 (16:03 -0700)]
[XFRM]: beet: fix IP option decapsulation
Beet mode looks for the beet pseudo header after the outer IP header,
which is wrong since that is followed by the ESP header. Additionally
it needs to adjust the packet length after removing the pseudo header
and point the data pointer to the real data location.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Thu, 5 Apr 2007 22:59:41 +0000 (15:59 -0700)]
[XFRM]: beet: fix beet mode decapsulation
Beet mode decapsulation fails to properly set up the skb pointers, which
only works by accident in combination with CONFIG_NETFILTER, since in that
case the skb is fixed up in xfrm4_input before passing it to the netfilter
hooks.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Thu, 5 Apr 2007 22:54:39 +0000 (15:54 -0700)]
[XFRM]: beet: use IPOPT_NOP for option padding
draft-nikander-esp-beet-mode-07.txt states "The padding MUST be filled
with NOP options as defined in Internet Protocol [1] section 3.1
Internet header format.", so do that.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
IB/iser: Don't defer connection failure notification to workqueue
When a connection is terminated asynchronously from the iSCSI layer's
perspective, iSER needs to notify the iSCSI layer that the connection
has failed. This is done using a workqueue (switched to from the iSER
tasklet context). Meanwhile, the connection object (that holds the
work struct) is released. If the workqueue function wasn't called
yet, it will be called later with a NULL pointer, which will crash the
kernel.
The context switch (tasklet to workqueue) is not required, and
everything can be done from the iSER tasklet. This eliminates the NULL
work struct bug (and simplifies the code).
Signed-off-by: Erez Zilber <erezz@voltaire.com> Signed-off-by: Roland Dreier <rolandd@cisco.com>
Adam Kropelin [Thu, 5 Apr 2007 14:06:30 +0000 (16:06 +0200)]
HID: Do not discard truncated input reports
Truncated reports should not be discarded since it prevents buggy
devices from communicating with userspace.
Prior to the regession introduced in 2.6.20, a shorter-than-expected
report in hid_input_report() was passed thru after having the missing
bytes cleared. This behavior was established over a few patches in the
2.6.early-teens days, including commit cd6104572bca9e4afe0dcdb8ecd65ef90b01297b.
This patch restores the previous behavior and fixes the regression.
Signed-off-by: Adam Kropelin <akropel1@rochester.rr.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Herbert Xu [Thu, 5 Apr 2007 07:07:39 +0000 (00:07 -0700)]
[IPSEC]: Reject packets within replay window but outside the bit mask
Up until this point we've accepted replay window settings greater than
32 but our bit mask can only accomodate 32 packets. Thus any packet
with a sequence number within the window but outside the bit mask would
be accepted.
This patch causes those packets to be rejected instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
[IPv6]: Exclude truncated packets from InHdrErrors statistics
Incoming trancated packets are counted as not only InTruncatedPkts but
also InHdrErrors. They should be counted as InTruncatedPkts only.
Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Jean Delvare [Thu, 5 Apr 2007 06:52:46 +0000 (23:52 -0700)]
[APPLETALK]: Fix a remotely triggerable crash
When we receive an AppleTalk frame shorter than what its header says,
we still attempt to verify its checksum, and trip on the BUG_ON() at
the end of function atalk_sum_skb() because of the length mismatch.
This has security implications because this can be triggered by simply
sending a specially crafted ethernet frame to a target victim,
effectively crashing that host. Thus this qualifies, I think, as a
remote DoS. Here is the frame I used to trigger the crash, in npg
format:
<Appletalk Killer>
{
# Ethernet header -----
XX XX XX XX XX XX # Destination MAC
00 00 00 00 00 00 # Source MAC
00 1D # Length
The destination MAC address must be set to those of the victim.
The severity is mitigated by two requirements:
* The target host must have the appletalk kernel module loaded. I
suspect this isn't so frequent.
* AppleTalk frames are non-IP, thus I guess they can only travel on
local networks. I am no network expert though, maybe it is possible
to somehow encapsulate AppleTalk packets over IP.
The bug has been reported back in June 2004:
http://bugzilla.kernel.org/show_bug.cgi?id=2979
But it wasn't investigated, and was closed in July 2006 as both
reporters had vanished meanwhile.
This code was new in kernel 2.6.0-test5:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2
And not modified since then, so we can assume that vanilla kernels
2.6.0-test5 and later, and distribution kernels based thereon, are
affected.
Note that I still do not know for sure what triggered the bug in the
real-world cases. The frame could have been corrupted by the kernel if
we have a bug hiding somewhere. But more likely, we are receiving the
faulty frame from the network.
Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
john stultz [Thu, 5 Apr 2007 02:08:24 +0000 (19:08 -0700)]
[PATCH] fix jiffies clocksource inittime
In debugging a problem w/ the -rt tree, I noticed that on systems that mark
the tsc as unstable before it is registered, the TSC would still be
selected and used for a short period of time. Digging in it looks to be a
result of the mix of the clocksource list changes and my clocksource
initialization changes.
With the -rt tree, using a bad TSC, even for a short period of time can
results in a hang at boot. I was not able to reproduce this hang w/
mainline, but I'm not completely certain that someone won't trip on it.
This patch resolves the issue by initializing the jiffies clocksource
earlier so a bad TSC won't get selected just because nothing else is yet
registered.
Signed-off-by: John Stultz <johnstul@us.ibm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] cciss: add init of drv->cylinders back to cciss_geometry_inquiry
This patch adds initialization of drv->cylinders back into the failing case in
cciss_geometry_inquiry. I inadvertently removed it in one my 2TB updates.
Signed-off-by: Mike Miller <mike.miller@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andrew Morton [Thu, 5 Apr 2007 02:08:22 +0000 (19:08 -0700)]
[PATCH] remove protection of LANANA-reserved majors
Revert all this. It can cause device-mapper to receive a different major from
earlier kernels and it turns out that the Amanda backup program (via GNU tar,
apparently) checks major numbers on files when performing incremental backups.
Which is a bit broken of Amanda (or tar), but this feature isn't important
enough to justify the churn.
Fix a bug in the swsusp's memory shrinker that causes some systems using
highmem to refuse to suspend to disk if image_size is set above 1/2 of
available RAM.
Special thanks to Jiri Slaby for reporting the problem and assistance in
debugging it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Adrian Bunk [Thu, 5 Apr 2007 02:08:21 +0000 (19:08 -0700)]
[PATCH] net/sunrpc/svcsock.c: fix a check
The return value of kernel_recvmsg() should be assigned to "err", not
compared with the random value of a never initialized "err" (and the "< 0"
check wrongly always returned false since == comparisons never have a
result < 0).
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With this patch we run the kobject_del via schedule_work so as to
avoid the deadlock.
Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch adds 2 missing symbol exports: jiffies_to_timeval() and
timeval_to_jiffies(). The (not yet merged) dm-raid4-5 module will need
them, and they used to be indirectly exported by virtue of being inline
functions.
Commit 8b9365d753d9870bb6451504c13570b81923228f ("[PATCH] Uninline
jiffies.h functions") uninlined them, and thus modules now need them
explicitly exported to use them.
Signed-off-by: Thomas Bittermann <t.bittermann@online.de> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: john stultz <johnstul@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge branch 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6:
[S390] cio: Fix handling of interrupt for csch().
[S390] page_mkclean data corruption.
The generic networking code ensures that no two networking devices
have the same name, so there is no time except when sysfs has
implementation bugs that device_rename when called from
dev_change_name will fail.
The current error handling for errors from device_rename in
dev_change_name is wrong and results in an unusable and unrecoverable
network device if device_rename is happens to return an error.
This patch removes the buggy error handling. Which confines the mess
when device_rename hits a problem to sysfs, instead of propagating it
the rest of the network stack. Making linux a little more robust.
Without this patch you can observe what happens when sysfs has a bug
when CONFIG_SYSFS_DEPRECATED is not set and you attempt to rename
a real network device to a name like (broken_parity_status, device,
modalias, power, resource2, subsystem_vendor, class, driver, irq,
msi_bus, resource, subsystem, uevent, config, enable, local_cpus,
numa_node, resource0, subsystem_device, vendor)
Greg has a patch that fixes the sysfs bugs but he doesn't trust it
for a 2.6.21 timeframe. This patch which just ignores errors should
be safe and it keeps the system from going completely wacky.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Howells [Mon, 2 Apr 2007 22:46:28 +0000 (23:46 +0100)]
[PATCH] SLAB: Mention slab name when listing corrupt objects
Mention the slab name when listing corrupt objects. Although the function
that released the memory is mentioned, that is frequently ambiguous as such
functions often release several pieces of memory.
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata: Limit ATAPI DMA to R/W commands only for TORiSAN DVD drives (take 3)
libata: Limit max sector to 128 for TORiSAN DVD drives (take 3)
libata: Clear tf before doing request sense (take 3)
libata: reorder HSM_ST_FIRST for easier decoding (take 3)
libata bugfix: preserve LBA bit for HDIO_DRIVE_TASK
2.6.21 fix lba48 bug in libata fill_result_tf()
Robert Hancock [Tue, 3 Apr 2007 04:05:29 +0000 (22:05 -0600)]
[PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
Windows driver .inf files. There are some confirming reports of problems
with these drives under Linux (for example http://lkml.org/lkml/2007/3/4/178)
so let's disable NCQ on these drives.
[ I'm personally starting to wonder whether we shouldn't disable NCQ by
default, and perhaps have a white-list. There seems to be a *lot* of
drives that do this wrong.. - Linus ]
Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
r8169: fix suspend/resume for down interface
r8169: issue request_irq after the private data are completely initialized
b44: fix IFF_ALLMULTI handling of CAM slots
cxgb3 - Firwmare update
cxgb3 - Tighten xgmac workaround
cxgb3 - detect NIC only adapters
cxgb3 - Safeguard TCAM size usage
The effect of the two changes is that for every call to
clear_page_dirty_for_io a page_test_and_clear_dirty is done. If
the per page dirty bit is set set_page_dirty is called. Strangly
clear_page_dirty_for_io is called for not-uptodate pages, e.g.
over this call-chain:
The bad news now is that page_test_and_clear_dirty might claim
that a not-uptodate page is dirty since SetPageUptodate which
resets the per page dirty bit has not yet been called. The page
writeback that follows clobbers the data on disk.
The simplest solution to this problem is to move the call to
page_test_and_clear_dirty under the "if (page_mapped(page))".
If a file backed page is mapped it is uptodate.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Albert Lee [Mon, 2 Apr 2007 03:34:15 +0000 (11:34 +0800)]
libata: Limit max sector to 128 for TORiSAN DVD drives (take 3)
patch 3/4:
The TORiSAN drive locks up when max sector == 256.
Limit max sector to 128 for the TORiSAN DRD-N216 drives.
(http://bugzilla.kernel.org/show_bug.cgi?id=6710)
Signed-off-by: Albert Lee <albertcc@tw.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Based on this, those last two statements fill_result_tf()
appear to me to be in the wrong order, in that the tf->flags
are uninitialized at the point where tf_read() is invoked.
So for lba48 commands, tf_read() won't be reading back the
full lba48 register contents..
Correct?
This patch corrects fill_result_tf() so that the flags
get copied to result_tf before they are used by tf_read().
Signed-off-by: Mark Lord <mlord@pobox.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
The PM hooks are no-op if the r8169 interface is down (i.e. !IFF_UP).
However, as the chipset is enabled, the device will not work after a
suspend/resume cycle. The patch always issue the required PCI suspend
sequence and removes the module unload/reload workaround.
r8169: issue request_irq after the private data are completely initialized
The irq handler schedules a NAPI poll request unconditionally as soon as
the status register is not clean. It has been there - and wrong - for
ages but a recent timing change made it apparently easier to trigger.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Jeff Garzik <jeff@garzik.org>
If you set the IFF_ALLMULTI flag on a b44 device, or if you join more than
B44_MCAST_TABLE_SIZE multicast groups, the device will stop receiving unicast
messages. This is because the __b44_set_mac_addr call sets the zeroth CAM
entry to the MAC address of the device, and then the loop at line 1722
proceeds to overwrite it unless the value of i is set by the __b44_load_mcast
call. However, when IFF_ALLMULTI is set, that call is bypassed, leaving i set
to zero.
Fixed by starting the loop at 1 to make it skip the CAM entry for the MAC
address.
Signed-off-by: Bill Helfinstine <bhelf@flitterfly.whirpon.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
[PATCH] msi: synchronously mask and unmask msi-x irqs.
This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams <mitch.a.williams@intel.com>.
When we mask or unmask a msi-x irqs the writes may be posted because
we are writing to memory mapped region. This means the mask and
unmask don't happen immediately but at some unspecified time in the
future. Which is out of sync with how the mask/unmask logic work
for ioapic irqs.
The practical result is that we get very subtle and hard to track down
irq migration bugs.
This patch performs a read flush after writes to the MSI-X table for mask
and unmask operations. Since the SMP affinity is set while the interrupt
is masked, and since it's unmasked immediately after, no additional flushes
are required in the various affinity setting routines.
The testing by Mitch Williams on his especially problematic system should
still be valid as I have only simplified the code, not changed the
functionality.
We currently have 7 drivers: cciss, mthca, cxgb3, forceth, s2io,
pcie/portdrv_core, and qla2xxx in 2.6.21 that are affected by this
problem when the hardware they driver is plugged into the right slot.
Given the difficulty of reproducing this bug and tracing it down to
anything that even remotely resembles a cause, even if people are
being affected we aren't likely to see many meaningful bug reports, and
the people who see this bug aren't likely to be able to reproduce this
bug in a timely fashion. So it is best to get this problem fixed
as soon as we can so people don't have problems.
Then if people do have a kernel message stating "No irq for vector" we
will know it is yet another novel cause that needs a complete new
investigation.
Cc: Greg KH <greg@kroah.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by: Mitch Williams <mitch.a.williams@intel.com> Acked-by: "Siddha, Suresh B" <suresh.b.siddha@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SCSI]: Fix scsi_send_eh_cmnd scatterlist handling
[SPARC]: Add unsigned to unused bit field in a.out.h
The sense buffer code in scsi_send_eh_cmnd was changed to use
alloc_page() and a scatter list, but the sense data copy was not
updated to match so what we actually get in the sense buffer is total
grabage starting with the kernel address of the struct page we got.
Basically the stack frame of scsi_send_eh_cmd() is what ends up
in the sense buffer.
Depending upon how pointers look on a given platform, you can
end up getting sr_ioctl.c errors when you mount a cdrom. If
the CDROM gives a check condition for GPCMD_GET_CONFIGURATION issued
by drivers/cdrom/cdrom.c:cdrom_mmc_profile(), sr_ioctl will
spit out this error message in sr_do_ioctl() with the way pointers
are on sparc64:
Michael Chan [Fri, 30 Mar 2007 21:53:06 +0000 (14:53 -0700)]
[BNX2]: Fix nvram write logic.
The nvram dword alignment logic was broken when writing less than 4
bytes on a non-aligned offset. It was missing logic to round the
length to 4 bytes.
The page erase code is also moved so that it is only called when
using non-buffered flash for better code clarity.
Update version to 1.5.7.
Based on initial patch from Tony Cureington <tony.cureington@hp.com>.
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
[IPv6]: Fix incorrect length check in rawv6_sendmsg()
In article <20070329.142644.70222545.davem@davemloft.net> (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), David Miller <davem@davemloft.net> says:
> From: Sridhar Samudrala <sri@us.ibm.com>
> Date: Thu, 29 Mar 2007 14:17:28 -0700
>
> > The check for length in rawv6_sendmsg() is incorrect.
> > As len is an unsigned int, (len < 0) will never be TRUE.
> > I think checking for IPV6_MAXPLEN(65535) is better.
> >
> > Is it possible to send ipv6 jumbo packets using raw
> > sockets? If so, we can remove this check.
>
> I don't see why such a limitation against jumbo would exist,
> does anyone else?
>
> Thanks for catching this Sridhar. A good compiler should simply
> fail to compile "if (x < 0)" when 'x' is an unsigned type, don't
> you think :-)
Dave, we use "int" for returning value,
so we should fix this anyway, IMHO;
we should not allow len > INT_MAX.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Acked-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
[NET]: Change "not found" return value for rule lookup
This changes the "not found" error return for the lookup
function to -ESRCH so that it can be distinguished from
the case where a rule or route resulting in -ENETUNREACH
has been found during the search.
It fixes a bug where if DECnet was compiled with routing
support, but no routes were added to the routing table,
it was failing to fall back to endnode routing.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Patrick Caulfield <pcaulfie@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6:
[PATCH] x86: Don't probe for DDC on VBE1.2
[PATCH] x86-64: Increase NMI watchdog probing timeout
[PATCH] x86-64: Let oprofile reserve MSR on all CPUs
[PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
Thomas Gleixner [Mon, 2 Apr 2007 12:25:31 +0000 (14:25 +0200)]
[PATCH] i386: fix file_read_actor() and pipe_read() for original i386 systems
The __copy_to_user_inatomic() calls in file_read_actor() and pipe_read()
are broken on original i386 machines, where WP-works-ok == false, as
__copy_to_user_inatomic() on such systems calls functions which might
sleep and/or contain cond_resched() calls inside of a kmap_atomic()
region.
The original check for WP-works-ok was in access_ok(), but got moved
during the 2.5 series to fix a race vs. swap.
Return the number of bytes to copy in the case where we are in an atomic
region, so the non atomic code pathes in file_read_actor() and
pipe_read() are taken.
This could be optimized to avoid the kmap_atomicby moving the check for
WP-works-ok into fault_in_pages_writeable(), but this is more intrusive
and can be done later.
[PATCH] vt: fix potential race in VT_WAITACTIVE handler
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0 if
fg_console has already been updated in redraw_screen() but the console
switch itself hasn't been completed. Fix this by checking fg_console in
vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski <spock@gentoo.org> Acked-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the regression resulting from the recent change of suspend code
ordering that causes systems based on Intel x86 CPUs using the microcode
driver to hang during the resume.
The problem occurs since the microcode driver uses request_firmware() in
its CPU hotplug notifier, which is called after tasks has been frozen and
hangs. It can be fixed by telling the microcode driver to use the
microcode stored in memory during the resume instead of trying to load it
from disk.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Adrian Bunk <bunk@stusta.de> Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk> Cc: Pavel Machek <pavel@ucw.cz> Cc: Maxim <maximlevitsky@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Brownell [Mon, 2 Apr 2007 06:49:47 +0000 (23:49 -0700)]
[PATCH] rtc-cmos lockdep fix, irq updates
Lockdep reported cmos_suspend() and cmos_resume() calling rtc_update_irq()
with IRQs enabled; not allowed.
Also fix problems seen on some hardware, whereby false alarm IRQs could be
reported (primarily to userspace); and update two comments to match changes
in ACPI. Those make up most of this patch, by volume.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
"When we block_prepare_write() failed while ext3_prepare_write() we jump to
"failure" label and call ext3_prepare_failure() witch search last mapped bh
and invoke commit_write untill it. This is wrong!! because some bh from
begining to the last mapped bh may be not uptodate. As a result we commit to
disk not uptodate page content witch contains garbage from previous usage."
and
"Unexpected file size increasing."
Call trace the same as it was in first issue but result is different.
For example we have file with i_size is zero. we want write two blocks ,
but fs has only one free block.
->ext3_prepare_write(...from == 0, to == 2048)
retry:
->block_prepare_write() == -ENOSPC# we failed but allocated one block here.
->ext3_prepare_failure()
->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :)
if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries))
goto retry;
Finally when all retries will be spended ext3_prepare_failure return
-ENOSPC, but i_size was increased and later block trimm procedures can't
help here.
We don't appear to have the horsepower to fix these issues, so let's put
things back the way they were for now.
projects / linux-2.6 / log