IO resource and ioremap debugging uncovered this ioremap() done
by drivers/pci/hotplug/ibmphp_ebda.c:
initcall pci_hotplug_init+0x0/0x41 returned 0 after 3 msecs
calling ibmphp_init+0x0/0x360 @ 1
ibmphpd: IBM Hot Plug PCI Controller Driver version: 0.6
resource map sanity check conflict: 0x9f800 0xaf5e7 0x9f800 0x9ffff reserved
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:175 __ioremap_caller+0x5c/0x226()
Pid: 1, comm: swapper Not tainted 2.6.27-rc7-tip-00914-g347b10f-dirty #36038
[<c013a72d>] warn_on_slowpath+0x41/0x68
[<c0156f00>] ? __lock_acquire+0x9ba/0xa7f
[<c012158c>] ? do_flush_tlb_all+0x0/0x59
[<c015ac31>] ? smp_call_function_mask+0x74/0x17d
[<c012158c>] ? do_flush_tlb_all+0x0/0x59
[<c013b228>] ? printk+0x1a/0x1c
[<c013f302>] ? iomem_map_sanity_check+0x82/0x8c
[<c0a773e8>] ? _read_unlock+0x22/0x25
[<c013f302>] ? iomem_map_sanity_check+0x82/0x8c
[<c0154e17>] ? trace_hardirqs_off+0xb/0xd
[<c0127731>] __ioremap_caller+0x5c/0x226
[<c0156158>] ? trace_hardirqs_on+0xb/0xd
[<c012767d>] ? iounmap+0x9d/0xa5
[<c01279dd>] ioremap_nocache+0x15/0x17
[<c0403c42>] ? ioremap+0xd/0xf
[<c0403c42>] ioremap+0xd/0xf
[<c0f1928f>] ibmphp_access_ebda+0x60/0xa0e
[<c0f17f64>] ibmphp_init+0xb5/0x360
[<c0101057>] do_one_initcall+0x57/0x138
[<c0f17eaf>] ? ibmphp_init+0x0/0x360
[<c0156158>] ? trace_hardirqs_on+0xb/0xd
[<c0148d75>] ? __queue_work+0x2b/0x30
[<c0f17eaf>] ? ibmphp_init+0x0/0x360
[<c0f015a0>] kernel_init+0x17b/0x1e2
[<c0f01425>] ? kernel_init+0x0/0x1e2
[<c01178b3>] kernel_thread_helper+0x7/0x10
=======================
---[ end trace a7919e7f17c0a725 ]---
initcall ibmphp_init+0x0/0x360 returned -19 after 144 msecs
calling zt5550_init+0x0/0x6a @ 1
the problem is this code:
io_mem = ioremap (ebda_seg<<4, 65000);
it assumes that the EBDA is 65000 bytes. But BIOS EBDA pointers are
at most 1K large.
_if_ the Rio code truly extends upon the customary EBDA size it needs
to iounmap() this memory and ioremap() it larger, once it knows it from
the generic descriptors that a Rio system is around.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch adds barrier support to GFS2. There is not a lot of change
really... we just add the barrier flag when we write journal header
blocks. If the underlying device refuses to support them, we fall back
to the previous way of doing things (wait for the I/O and hope) since
there is nothing else we can do. There is no user configuration,
barriers will always be on unless the device refuses to support them.
This seems a reasonable solution to me since this is a correctness
issue.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
fix this build error:
kernel/resource.c: In function 'iomem_map_sanity_check':
kernel/resource.c:842: error: implicit declaration of function 'r_next'
kernel/resource.c:842: warning: assignment makes pointer from integer without a cast
r_next() was only available if CONFIG_PROCFS was enabled.
and fix this build warning:
kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
kernel/resource.c:855: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'
resource_t can be 32 bits.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Go through the iomem resource tree to check if any of the ioremap()
requests span more than any slot in the iomem resource tree and do
a WARN_ON() if we hit this check.
This will raise a red-flag, if some driver is mapping more than what
is needed. And hopefully identify possible corruptions much earlier.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch adds specific power-off method for Buffalo Linkstation Mini
board. The board has a hardware switch which should be monitored from
userspace. When the switch is in OFF position the board should be rebooted
and U-Boot will start in an idle mode and wait for the user to move the
power switch back to ON position.
Signed-off-by: Alexey Kopytko <alexey@kopytko.ru>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Yet another bug was found in xfs_iext_irec_compact_full() and while the
source of the bug was found it wasn't an easy task to track it down
because the conditions are very difficult to reproduce.
A HUGE thank-you goes to Russell Cattelan and Eric Sandeen for their
significant effort in tracking down the source of this corruption.
xfs_iext_irec_compact_full() and xfs_iext_irec_compact_pages() are almost
identical - they both compact indirect extent lists by moving extents from
subsequent buffers into earlier ones. xfs_iext_irec_compact_pages() only
moves extents if all of the extents in the next buffer will fit into the
empty space in the buffer before it. xfs_iext_irec_compact_full() will go
a step further and move part of the next buffer if all the extents wont
fit. It will then shift the remaining extents in the next buffer up to the
start of the buffer. The bug here was that we did not update er_extoff and
this caused extent list corruption.
It does not appear that this extra functionality gains us much. Calling
xfs_iext_irec_compact_pages() instead will do a good enough job at
compacting the indirect list and will be quicker too.
For the case in xfs_iext_indirect_to_direct() the total number of extents
in the indirect list will fit into one buffer so we will never need the
extra functionality of xfs_iext_irec_compact_full() there.
Also xfs_iext_irec_compact_pages() doesn't need to do a memmove() (the
buffers will never overlap) so we don't want the performance hit that can
incur.
SGI-PV: 987159
SGI-Modid: xfs-linux-melb:xfs-kern:32166a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
If we don't move all the records from the next buffer into the current
buffer then we need to update the er_extoff field of the next buffer as we
shift the remaining records to the start of the buffer.
SGI-PV: 987159
SGI-Modid: xfs-linux-melb:xfs-kern:32165a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Russell Cattelan <cattelan@thebarn.com>
Remove hand-rolled get_unaligned_be16, this points to a possible bug as
bq27x00_read does another endian byteswap which sparse notices:
drivers/power/bq27x00_battery.c:81:14: warning: cast to restricted __be16
Which should probably be checked.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
tosa_battery should also depend on wm97xx_ts as it uses dac-accessing
functions from that module.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Commit ee1e2c82 ("IPoIB: Refresh paths instead of flushing them on SM
change events") changed how paths are flushed on an SM event. This
change introduces a problem if the path record query triggered by
fails, causing path->ah to become NULL. A later successful path query
will then trigger WARN_ON() in path_rec_completion(), and crash
because path->ah has already been freed, so the ipoib_put_ah() inside
the lock in path_rec_completion() may actually drop the last reference
(contrary to the comment that claims this is safe).
Fix this by updating path->ah and freeing old_ah only when the path
record query is successful. This prevents the neighbour AH and that
path AH from getting out of sync.
This fixes <https://bugs.openfabrics.org/show_bug.cgi?id=1194>
Reported-by: Rabah Salem <ravah@mellanox.com>
Debugged-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We can translate a struct page directly to a DMA address using
page_to_dma(). No need to use page_address() followed by
virt_to_dma().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit ee1e2c82 ("IPoIB: Refresh paths instead of flushing them on SM
change events") changed how paths are flushed on an SM event. This
change introduces a problem if the path record query triggered by
fails, causing path->ah to become NULL. A later successful path query
will then trigger WARN_ON() in path_rec_completion(), and crash
because path->ah has already been freed, so the ipoib_put_ah() inside
the lock in path_rec_completion() may actually drop the last reference
(contrary to the comment that claims this is safe).
Fix this by updating path->ah and freeing old_ah only when the path
record query is successful. This prevents the neighbour AH and that
path AH from getting out of sync.
This fixes <https://bugs.openfabrics.org/show_bug.cgi?id=1194>
Reported-by: Rabah Salem <ravah@mellanox.com>
Debugged-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
This patch adds support for Buffalo Linkstation Mini board.
Signed-off-by: Alexey Kopytko <alexey@kopytko.ru>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Feroceon L2 cache can work in eighther write through or write back mode
on Kirkwood. Add the option to configure this mode according to Kconfig.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
This patch provides standard GPIO LED control
for the ED Mini V2, with software blinking only
(CPLD hardware blinking capability is not used).
This patch also provides status of the power
button as a standard GPIO input event.
Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Remove uart1 init calls for boards that use the physical pins onto
which the UART1 signals are multiplexed for different purposes.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Add support to the Kirkwood port for newer device models and silicon
revisions. Instead of looking at the DEVICE_ID register, the device
version is now determined by looking at the PCI-Express device ID and
revision registers, as it is done for orion5x, and this information
is used to determine the TCLK frequency, again, as it is done for
orion5x.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Currently, kirkwood uses a hardcoded timer tick rate of 166 MHz, but
the actual timer tick rate varies between different members of the SoC
family.
This patch prepares for runtime determination of the timer tick rate.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
The RD88F6183AP-GE is an access point reference design for the
88F6183 SoC, with a 88E6161 six-port gigabit ethernet switch with
five PHYs (providing 1 WAN and 4 LAN ports and an interface to the
CPU), and a mini-PCIe slot for a wireless card.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
The Orion-1-90 (88F6183) is another member of the Orion SoC family,
which has a 16 bit DDR2 interface, one x1 PCIe port (configurable as
Root Complex or Endpoint), one 10/100/1000 ethernet interface, one
USB 2.0 port with PHY, one SPDIF/I2S interface, one SDIO interface,
one TWSI interface, two UARTs, one SPI interface, a NAND controller,
a crypto engine, and a 4-channel DMA engine.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This patch adds support for the Buffalo Terastation Pro II/Live.
Signed-off-by: Sylver Bruneau <sylver.bruneau@googlemail.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This patch adds support for the LaCie Ethernet Disk mini V2.
Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
Signed-off-by: Christopher Moore <moore@free.fr>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Currently, orion5x uses a hardcoded timer tick rate of 166 MHz, but
the actual timer tick rate varies between different members of the SoC
family (and can vary based on strap pin settings).
This patch prepares for runtime determination of the timer tick rate.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Wire up the ethernet port's error interrupt so that the
mv643xx_eth driver can sleep for SMI event completion instead of
having to busy-wait for it.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Wire up the ethernet port's error interrupt so that the
mv643xx_eth driver can sleep for SMI event completion instead of
having to busy-wait for it.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Wire up the ethernet port's error interrupt so that the
mv643xx_eth driver can sleep for SMI event completion instead of
having to busy-wait for it.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Btrfs metadata writeback is fairly expensive. Once a tree block is written
it must be cowed before it can be changed again. The btree writepages
code has a threshold based on a count of dirty btree bytes which is
updated as IO is sent out.
This changes btree_writepages to skip the writeout if there are less
than 32MB of dirty bytes from the btrees, improving performance
across many workloads.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
The code to free block groups needs to drop the space info spin lock
before calling btrfs_remove_free_space_cache (which can schedule).
This is safe because at unmount time, nobody else is going to play
with the block groups.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Btrfs had compatibility code for kernels back to 2.6.18. These have
been removed, and will be maintained in a separate backport
git tree from now on.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
After a crash, the tree log code uses btrfs_alloc_logged_extent to
record allocations of data extents that it finds in the log tree. These
come in basically random order, which does not fit how
btrfs_remove_free_space() expects to be called.
btrfs_remove_free_space was changed to support recording an extent
allocation in the middle of a region of free space.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
btrfs had magic to put the chagneset id into a printk on module load.
This removes that from the Makefile and hardcodes the printk to print
"Btrfs"
Signed-off-by: Chris Mason <chris.mason@oracle.com>
The power_mutex lock in snd_pcm_drop may cause a possible deadlock
chain, and above all, it's unneeded. Let's get rid of it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The code to update the on disk i_size happens before the
ordered_extent record is removed. So, it is possible for multiple
ordered_extent completion routines to run at the same time, and to
find each other in the ordered tree.
The end result is they both decide not to update disk_i_size, leaving
it too small. This temporary fix just puts the updates inside
the extent_mutex. A real solution would be stronger ordering of
disk_i_size updates against removing the ordered extent from the tree.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This patch makes the back reference system to explicit record the
location of parent node for all types of extents. The location of
parent node is placed into the offset field of backref key. Every
time a tree block is balanced, the back references for the affected
lower level extents are updated.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Tree log blocks are only reserved, and should not ever get fully
allocated on disk. This check makes sure they stay out of the
extent tree.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Tree blocks were using async bio submission, but the sum was still
being done directly during writepage. This moves the checksumming
into the worker thread.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
1) replace the per fs_info extent_io_tree that tracked free space with two
rb-trees per block group to track free space areas via offset and size. The
reason to do this is because most allocations come with a hint byte where to
start, so we can usually find a chunk of free space at that hint byte to satisfy
the allocation and get good space packing. If we cannot find free space at or
after the given offset we fall back on looking for a chunk of the given size as
close to that given offset as possible. When we fall back on the size search we
also try to find a slot as close to the size we want as possible, to avoid
breaking small chunks off of huge areas if possible.
2) remove the extent_io_tree that tracked the block group cache from fs_info and
replaced it with an rb-tree thats tracks block group cache via offset. also
added a per space_info list that tracks the block group cache for the particular
space so we can lookup related block groups easily.
3) cleaned up the allocation code to make it a little easier to read and a
little less complicated. Basically there are 3 steps, first look from our
provided hint. If we couldn't find from that given hint, start back at our
original search start and look for space from there. If that fails try to
allocate space if we can and start looking again. If not we're screwed and need
to start over again.
4) small fixes. there were some issues in volumes.c where we wouldn't allocate
the rest of the disk. fixed cow_file_range to actually pass the alloc_hint,
which has helped a good bit in making the fs_mark test I run have semi-normal
results as we run out of space. Generally with data allocations we don't track
where we last allocated from, so everytime we did a data allocation we'd search
through every block group that we have looking for free space. Now searching a
block group with no free space isn't terribly time consuming, it was causing a
slight degradation as we got more data block groups. The alloc_hint has fixed
this slight degredation and made things semi-normal.
There is still one nagging problem I'm working on where we will get ENOSPC when
there is definitely plenty of space. This only happens with metadata
allocations, and only when we are almost full. So you generally hit the 85%
mark first, but sometimes you'll hit the BUG before you hit the 85% wall. I'm
still tracking it down, but until then this seems to be pretty stable and make a
significant performance gain.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
cache block group had a few bugs in the error handling code,
this makes sure paths get properly released and the correct return value
goes out.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
