This reverts commit 22eecde2f9. Uli
reports that it breaks UML on x86-64 with the Fedora 8 gcc (gcc 4.1.2),
causing a crash on startup. See
http://marc.info/?l=linux-kernel&m=121011722806093&w=2
for a trace.
Reported-by: Ulrich Drepper <drepper@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently, iw_cxgb3 is severely limited on the amount of userspace
memory that can be registered in in a single memory region, which
causes big problems for applications that expect to be able to
register 100s of MB.
The problem is that the driver uses a single kmalloc()ed buffer to
hold the physical buffer list (PBL) for the entire memory region
during registration, which means that 8 bytes of contiguous memory are
required for each page of memory being registered. For example, a 64
MB registration will require 128 KB of contiguous memory with 4 KB
pages, and it unlikely that such an allocation will succeed on a busy
system.
This is purely a driver problem: the temporary page list buffer is not
needed by the hardware, so we can fix this by writing the PBL to the
hardware in page-sized chunks rather than all at once. We do this by
splitting the memory registration operation up into several steps:
- Allocate PBL space in adapter memory for the full registration
- Copy PBL to adapter memory in chunks
- Allocate STag and enable memory region
This also allows several other cleanups to the __cxio_tpt_op()
interface and related parts of the driver.
This change leaves the reregister memory region and memory window
operations broken, but they already didn't work due to other
longstanding bugs, so fixing them will be left to a later patch.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Was a holdover from the old kernel_thread based cifsd
code. We needed to know that the thread had set the task variable
before proceeding. Now that kthread_run returns the new task, this
doesn't appear to be needed anymore.
As best I can tell, this sleep was intended to try to prevent
cifs_umount from freeing the cifsSesInfo struct before cifsd had
exited. Now that cifsd is using the kthread API, we know that
when kthread_stop returns that cifsd has exited, so I don't
think this is needed any longer.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Christop Hellwig <hch@infradead.org>
Signed-off-by: Steve French <sfrench@us.ibm.com>
We die because we forget to convert initrd_start and
initrd_end to virtual addresses.
Reported by Mikael Pettersson
Signed-off-by: David S. Miller <davem@davemloft.net>
Sparc doesn't have some of the OF interfaces this driver
wants to use.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Current iw_cxgb3 code adds PBL memory to the driver's gen_pool in 2 MB
chunks. This limits the largest single allocation that can be done to
the same size, which means that with 4 KB pages, each of which takes 8
bytes of PBL memory, the largest memory region that can be allocated
is 1 GB (256K PBL entries * 4 KB/entry).
Remove this limit by adding all the PBL memory in a single gen_pool
chunk, if possible. Add code that falls back to smaller chunks if
gen_pool_add() fails, which can happen if there is not sufficient
contiguous lowmem for the internal gen_pool bitmap.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Commit 33dcdac2df ("kill ->put_inode")
removed the final use of i_op->put_inode, but left the now totally
unused "op" variable in iput().
Get rid of it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix warning from pmd_bad() at bootup on a HIGHMEM64G HIGHPTE x86_32.
That came from 9fc34113f6 x86: debug pmd_bad();
but we understand now that the typecasting was wrong for PAE in the previous
version: pagetable pages above 4GB looked bad and stopped Arjan from booting.
And revert that cded932b75 x86: fix pmd_bad
and pud_bad to support huge pages. It was the wrong way round: we shouldn't
weaken every pmd_bad and pud_bad check to let huge pages slip through - in
part they check that we _don't_ have a huge page where it's not expected.
Put the x86 pmd_bad() and pud_bad() definitions back to what they have long
been: they can be improved (x86_32 should use PTE_MASK, to stop PAE thinking
junk in the upper word is good; and x86_64 should follow x86_32's stricter
comparison, to stop thinking any subset of required bits is good); but that
should be a later patch.
Fix Hans' good observation that follow_page() will never find pmd_huge()
because that would have already failed the pmd_bad test: test pmd_huge in
between the pmd_none and pmd_bad tests. Tighten x86's pmd_huge() check?
No, once it's a hugepage entry, it can get quite far from a good pmd: for
example, PROT_NONE leaves it with only ACCESSED of the KERN_PGTABLE bits.
However... though follow_page() contains this and another test for huge
pages, so it's nice to keep it working on them, where does it actually get
called on a huge page? get_user_pages() checks is_vm_hugetlb_page(vma) to
to call alternative hugetlb processing, as does unmap_vmas() and others.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Earlier-version-tested-by: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jeff Chua <jeff.chua.linux@gmail.com>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fcntl_setlk()/close() race prevention has a subtle hole - we need to
make sure that if we *do* have an fcntl/close race on SMP box, the
access to descriptor table and inode->i_flock won't get reordered.
As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs.
STORE descriptor table entry, LOAD inode->i_flock with not a single
lock in common on both sides. We do have BKL around the first STORE,
but check in locks_remove_posix() is outside of BKL and for a good
reason - we don't want BKL on common path of close(2).
Solution is to hold ->file_lock around fcheck() in there; that orders
us wrt removal from descriptor table that preceded locks_remove_posix()
on close path and we either come first (in which case eviction will be
handled by the close side) or we'll see the effect of close and do
eviction ourselves. Note that even though it's read-only access,
we do need ->file_lock here - rcu_read_lock() won't be enough to
order the things.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
And with that last patch to affs killing the last put_inode instance we
can finally, after many years of transition kill this racy and awkward
interface.
(It's kinda funny that even the description in
Documentation/filesystems/vfs.txt was entirely wrong..)
Also remove a very misleading comment above the defintion of
struct super_operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
- remove affs_put_inode, so preallocations aren't discared unnecessarily
often.
- remove affs_drop_inode, it's called with a spinlock held, so it can't
use a mutex.
- make i_opencnt atomic
- avoid direct b_count manipulations
- a few allocation failure fixes, so that these are more gracefully
handled now.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This patch is fixes the sequoia.dts device tree file to use the values defined
in the 440Epx data sheet from AMCC.
That fixes an issue where some devices, including graphics cards, would not
initialize properly because the PCI resource space was not big enough.
Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking the device_type property of the PCIe
device node ("pci" for root-complex and "pci-endpoint" for endpoint
configuration).
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
On a read error, e1000e might have returned uninitialized block of
eeprom data back to userspace. The convention is that 0xff is "empty",
so mark the entire eeprom as empty in case of an error.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Commit 9fb1e350e1,
ucc_geth: use rx-clock-name and tx-clock-name device tree properties
Introduced a typo that made the driver use the RX clock
as TX clock, causing massive TX errors.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Otherwise theoretically at least
CAP_NET_ADMIN
Reload new firmware
Wait..
Firmware patches kernel
So it should be CAY_SYS_RAWIO - not that I suspect this is in fact a
credible attack vector!
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Delete the non-napi code from the driver and Kconfig.
Tested x86_64. Apply at next open opportunity.
Signed-off-by: Don Fry <pcnet32@verizon.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
There are more memory leaks in the !PPC_CPM_NEW_BINDING case, but that code
will disappear soon along with arch/ppc.
Reported by Daniel Marjamki <danielm77@spray.se> at
http://bugzilla.kernel.org/show_bug.cgi?id=10591
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=10577
I was unable to access a computer containing an Intel EtherExpress 16 network
card using IPv6.
I traced this to failure of neighbour discovery. When I used an "ip -6 neigh
add" command, on the computer attempting access, to insert a binding between
the IPv6 address of the computer with the Intel EtherExpress 16 network card
and the card's ethernet address, I was able to access that computer using
IPv6.
Neighbour discovery requires working multicast. The driver sources file
eexpress.c contains an approximately 30 line function eexp_setup_filter used
when loading multicast addresses.
I found 3 problems in this function
1) It wrote the number of multicast addresses to the card instead of the
number of bytes in the multicast addresses.
2) When loading multiple multicast addresses it loaded the first one
provided multiple times instead of loading each one once.
3) The setting of pointer 'data' from 'dmi->dmi_addr' occured before the
test for the error situation of 'dmi' being NULL.
Correcting these problems allows the computer with the Intel EtherExpress 16
network card to found by IPv6 neighbour discovery.
p.s. There is some information on the Intel EtherExpress 16 at
http://www.intel.com/support/etherexpress/vintage/sb/cs-013500.htm
Datasheet for the Intel 82586 ethernet controller used by the card
http://www.datasheetcatalog.com/datasheets_pdf/8/2/5/8/82586.shtml
Signed-off-by: Bruce Robson <bns_robson@hotmail.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Use net_device_stats from net_device structure instead of local.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The ethernet card 3c980-TX needs a mdio_sync() to initialize the ethernet
properly. This is forced by adding an EXTRA_PREAMBLE to its drv_flags.
Without this, the driver did not reconnect after a link loss.
Signed-off-by: Gunnar Larisch <Gunnar.Larisch@gmx.de>
Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: (27 commits)
pata_atiixp: Don't disable
sata_inic162x: update intro comment, up the version and drop EXPERIMENTAL
sata_inic162x: add cardbus support
sata_inic162x: kill now unused SFF related stuff
sata_inic162x: use IDMA for ATAPI commands
sata_inic162x: use IDMA for non DMA ATA commands
sata_inic162x: kill now unused bmdma related stuff
sata_inic162x: use IDMA for ATA_PROT_DMA
sata_inic162x: update TF read handling
sata_inic162x: add / update constants
sata_inic162x: misc clean ups
sata_mv use hweight16() for bit counting (V2)
sata_mv NCQ-EH for FIS-based switching
sata_mv delayed eh handling
libata: export ata_eh_analyze_ncq_error
sata_mv new mv_port_intr function
sata_mv fix mv_host_intr bug for hc_irq_cause
sata_mv NCQ and SError fixes for mv_err_intr
sata_mv rearrange mv_config_fbs
sata_mv errata workaround for sata25 part 1
...
drivers/net/appletalk/cops.c: In function ‘cops_reset’:
drivers/net/appletalk/cops.c:507: warning: comparison of distinct pointer
types lacks a cast
by replacing hand-woven msleep() with call to msleep()
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch adds support for the BM PHY, a new PHY model being used
on ICH9-based implementations.
This new PHY exposes issues in the ICH9 silicon when receiving
jumbo frames large enough to use more than a certain part of the
Rx FIFO, and this unfortunately breaks packet split jumbo receives.
For this reason we re-introduce (for affected adapters only) the
jumbo single-skb receive routine back so that people who do
wish to use jumbo frames on these ich9 platforms can do so.
Part of this problem has to do with CPU sleep states and to make
sure that all the wake up timings are correctly we force them
with the recently merged pm_qos infrastructure written by Mark
Gross. (See http://lkml.org/lkml/2007/10/4/400).
To make code read a bit easier we introduce a _IS_ICH flag so
that we don't need to do mac type checks over the code.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch fixes uli526x driver's issues on a PowerPC boards: uli chip
is unable to receive the packets.
It appears that send_frame_filter prepares the setup frame in the
endianness unsafe manner. On a big endian machines we should shift
the address nibble by two bytes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
ucc_geth didn't have anything marked as __iomem. It was also inconsistent
with its use of in/out accessors (using them sometimes, not using them other
times). Cleaning this up cuts the warnings down from hundreds to just over a
dozen.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Declared some things static, declared some things in the header.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
During sparse cleanup, found a locking bug. Some of the sysfs functions were
acquiring a lock, and then returning in the event of an error. We rearrange
the code so that the lock is released in error conditions, too.
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
As part of:
commit c2edacf80e
Author: Jay Vosburgh <fubar@us.ibm.com>
Date: Mon Jul 9 10:42:47 2007 -0700
bonding / ipv6: no addrconf for slaves separately from master
two steps were rearranged in the enslavement process: netdev_set_master
is now before the call to dev_open to open the slave.
This patch updates the error cases and unwind process at the
end of bond_enslave to match the new order. Without this patch, it is
possible for the enslavement to fail, but leave the slave with IFF_SLAVE
set in its flags.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The sysfs layer has an internal protection, that ensures, that
all the process sitting inside ->sore/->show callback exits
before the appropriate entry is unregistered (the calltraces
are rather big, but I can provide them if required).
On the other hand, bonding takes rtnl_lock in
a) the bonding_store_bonds, i.e. in ->store callback,
b) module exit before calling the sysfs unregister routines.
Thus, the classical AB-BA deadlock may occur. To reproduce run
# while :; do modprobe bonding; rmmod bonding; done
and
# while :; do echo '+bond%d' > /sys/class/net/bonding_masters ; done
in parallel.
The fix is to move the bond_destroy_sysfs out of the rtnl_lock,
but _before_ bond_free_all to make sure no bonding devices exist
after module unload.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Fixed an error unwind in bonding_store_bonds that didn't release
the locks it held, and consolidated unwinds into a common block at the
end of the function. Bug reported by Pavel Emelyanov <xemul@openvz.org>,
who provided a different fix.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
If the call to bond_create_sysfs_entry in bond_create fails, the
proper rollback is to call unregister_netdevice, not free_netdev.
Otherwise - kernel BUG at net/core/dev.c:4057!
Checked with artificial failures injected into bond_create_sysfs_entry.
Pavel's original patch modified by Jay Vosburgh to move code around
for clarity (remove goto-hopping within the unwind block).
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
A couple of distributions (Fedora, Ubuntu) were having weird problems with the
ATI IXP series PATA controllers being reported as simplex. At the heart of
the problem is that both distros ignored the recommendations to load pata_acpi
and ata_generic *AFTER* specific host drivers.
The underlying cause however is that if you D3 and then D0 an ATI IXP it
helpfully throws away some configuration and won't let you rewrite it.
Add checks to ata_generic and pata_acpi to pin ATIIXP devices. Possibly the
real answer here is to quirk them and pin them, but right now we can't do that
before they've been pcim_enable()'d by a driver.
I'm indebted to David Gero for this. His bug report not only reported the
problem but identified the cause correctly and he had tested the right values
to prove what was going on
[If you backport this for 2.6.24 you will need to pull in the 2.6.25
removal of the bogus WARN_ON() in pcim_enagle]
Signed-off-by: Alan Cox <alan@redhat.com>
Tested-by: David Gero <davidg@havidave.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
sata_inic162x is now ready for production use. Bump the version,
explain what's working and what's not and drop EXPERIMENTAL.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When attached to cardbus, mmio region is at BAR 1. Other than that,
everything else is the same. Add support for it.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
sata_inic162x now doesn't use any SFF features. Remove all SFF
related stuff.
* Mask unsolicited ATA interrupts. This removes our primary source of
spurious interrupts and spurious interrupt handling can be tightened
up. There's no need to clear ATA interrupts by reading status
register either.
* Don't dance with IDMA_CTL_ATA_NIEN and simplify accesses to
IDMA_CTL.
* Inherit from sata_port_ops instead of ata_sff_port_ops.
* Don't initialize or use ioaddr. There's no need to map BAR0-4
anymore.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Use IDMA for ATAPI commands. Write and some misc commands time out
when executed using ATAPI_PROT_DMA but ATAPI_PROT_PIO works fine. As
PIO is driven by DMA too, it doesn't make any noticeable difference
for native SATA devices. inic_check_atapi_dma() is implemented to
force PIO for those ATAPI commands.
After this change, sata_inic162x issues all commands using IDMA.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Use IDMA for PIO and non-data commands. This allows sata_inic162x to
safely drive LBA48 devices. Kill inic_dev_config() which contains
code to reject LBA48 devices.
With this change, status checking in inic_qc_issue() to avoid hard
lock up after hotplug can go away too.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The modified driver on initio site has enough clue on how to use IDMA.
Use IDMA for ATA_PROT_DMA.
* LBA48 now works as long as it uses DMA (LBA48 devices still aren't
allowed as it can destroy data if PIO is used for any reason).
* No need to mask IRQs for read DMAs as IDMA_DONE is properly raised
after transfer to memory is actually completed. There will be some
spurious interrupts but host_intr will handle it correctly and
manipulating port IRQ mask interacts badly with the other port for
some reason, so command type dependent port IRQ masking is not used
anymore.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
inic162x can't reliably read back TF or at least we don't know how to
do it yet. The only values which seem reliable are status and error.
This patch updates access to TF.
* implement inic_tf_read() which reads the TF area in mmio area
* implement custom inic_qc_fill_rtf() which only returns true if
status indicates device error. it'll be returning bogus addresses
for device errors but it'll be able to report why it failed at
least.
* implement custom inic_check_ready() and use ata_wait_after_reset()
instead of the SFF version.
* use inic_tf_read() for classification.
This is not perfect but it fixes hotplug detection failure and at
least makes the driver report 0's instead of random garbages while
reporting valid status and error for device errors.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
