Well, almost. We'll actually keep a 'TEST_TOTLEN' macro set for now, and keep
doing some paranoia checks to make sure it's all working correctly. But if
TEST_TOTLEN is unset, the size of struct jffs2_raw_node_ref drops from 16
bytes to 12 on 32-bit machines. That's a saving of about half a megabyte of
memory on the OLPC prototype board, with 125K or so nodes in its 512MiB of
flash.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
We can't use jffs2_scan_dirty_space() because it doesn't do any locking; it's
only for use at scan time -- hence the 'scan' in the name.
Also, don't allocate refs while we have c->erase_completion_lock held.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
We don't allocate this locally any more -- it's given to us and owner by
our caller. Also improve the debug messages a little.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every
piece of dirty space in the system, so that __totlen can be killed off....
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
If __totlen is going away, we need to pass the length in separately.
Also stop callers from needlessly setting ref->next_phys to NULL,
since that's done for them... and since that'll also be going away soon.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Make sure we allocate a ref for any dirty space which exists between nodes
which we find in an eraseblock summary.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The incoming ref_totlen() calculation is going to rely on the existence
of nodes which cover all dirty space. We can't just tweak the accounting
data any more; we have to call jffs2_scan_dirty_space() to do it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
To eliminate the __totlen field from struct jffs2_raw_node_ref, we need
to allocate nodes for dirty space instead of just tweaking the accounting
data. Introduce jffs2_scan_dirty_space() in preparation for that.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
For RWCOMPAT and ROCOMPAT nodes, we should still allow the mount to
succeed. Just abandon the summary and fall through to the full scan.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
If we had to allocate extra space for the summary node, we weren't
correctly freeing it when jffs2_sum_scan_sumnode() returned nonzero --
which is both the success and the failure case. Only when it returned
zero, which means fall through to the full scan, were we correctly freeing
the buffer.
Document the meaning of those return codes while we're at it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
We should preserve these when we come to garbage collect them, not let
them get erased. Use jffs2_garbage_collect_pristine() for this, and make
sure the summary code copes -- just refrain from writing a summary for any
block which contains a node we don't understand.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
The same sequence of code was repeated in many places, to add a new
struct jffs2_raw_node_ref to an eraseblock and adjust the space accounting
accordingly. Move it out-of-line.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
We were calling ref_totlen() 18 times. Even before that becomes a real
function rather than just a dereference, apparently some compilers still
suck anyway. It'll _certainly_ suck after ref_totlen() becomes more
complicated, so calculate it once and don't rely on CSE.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This improves the time to mount 512MiB of NAND flash on my OLPC prototype
by about 4%. We used to read the last page of the eraseblock twice -- once
to find the offset of the summary node, and again to actually _read_ the
summary node. Now we read the last page only once, and read more only if
we need to.
We also don't allocate a new buffer just for the summary code -- we use
the buffer which was already allocated for the scan. Better still, if the
'buffer' for the scan is actually just a pointer directly into NOR flash,
we use that too, avoiding the memcpy() which we used to do.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Relax the lowmem bounce buffer requirement for imm so that any
low memory page will do -- they don't need to be below the
ISA 16 MB limit, just need to be mapped in low memory.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Semantic changes in ISP24xx firmware behaviour inadvertently
caused the driver to believe an F-port topology was present in an
N_port-to-N_port configuration.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Simplify and centralise buffer allocation/deallocation, as
there's no point in having two memory request methods.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Expandind on the previous commit:
commit 79f89a4296
Author: andrew.vasquez@qlogic.com <andrew.vasquez@qlogic.com>
Date: Fri Jan 13 17:05:58 2006 -0800
[SCSI] qla2xxx: Disable port-type RSCN handling via driver state-machine.
and given:
- the process-context requirements of the FC transport
rport-APIs.
- lack of port-type RSCN processing logic for ISP24xx and newer
chips.
it's time now to remove the state-machine logic from mainline.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
In qla2x00_reset_chip the driver first takes the hardware lock,
and then later on takes the mbx lock.
In the mailbox_command code.. it goes the other way around.
Discovered with the lock validator.
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
If firmware image is unavailable via request_firwmare(), then
attempt to load the image (likely out-of-date) stored in flash
memory.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
With ISP24XX and ISP54XX parts.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Do not flush queues then block session. This will cause commands
to needlessly swing around on us and remove goofy
recovery_failed field and replace with state value.
And do not start recovery from within the host reset function.
This causeis too many problems becuase open-iscsi was desinged to
call out to userspace then have userpscae decide if we should
go into recovery or kill the session.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Patch from david.somayajulu@qlogic.com and cleaned up by Tomo.
qla4xxx is going to have a different daemon so this patch
just routes the events to the right daemon.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Discovered by steven@hayter.me.uk and patch by michaelc@cs.wisc.edu
The dtask mempool is reserving 261120 items per session! Since we are now
sending headers with sendmsg there is no reason for the mempool and that
was causing us to us carzy amounts of mem. We can preallicate a header in
the r2t and task struct and reuse them
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
We only use the mtask data buffer for login tasks so we do not
need to preallocate a buffer for every mtask. This saves
8 * 31 KB.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
From Zhen and ported by Mike:
Don't use sendpage for the headers. sendpage for the pdu headers
does not seem to have a performance impact, makes life harder
for mutiple data pdus to be in flight and still trips up some
network cards when it is from slab mem.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The Coverity checker found a memory leak (bug nr. 1245) in
drivers/block/DAC960.c::DAC960_V2_ProcessCompletedCommand()
The leak is pretty unlikely since it requires that the first of two
successive kmalloc() calls fail while the second one succeeds. But it can
still happen even if it's unlikely.
If the first call that allocates 'PhysicalDeviceInfo' fails but the one
that allocates 'InquiryUnitSerialNumber' succeeds, then we will leak the
memory allocated to 'InquiryUnitSerialNumber' when the variable goes out
of scope.
A simple fix for this is to change the existing code that frees
'PhysicalDeviceInfo' if that one was allocated but
'InquiryUnitSerialNumber' was not, into a check for either pointer
being NULL and if so just free both. This is safe since kfree() can
deal with being passed a NULL pointer and it avoids the leak.
While I was there I also removed the casts of the kmalloc() return
value since it's pointless.
I also updated the driver version since this patch changes the workings of
the code (however slightly).
This issue could probably be fixed a lot more elegantly, but the code
is a big mess IMHO and I just took the least intrusive route to a fix
that I could find instead of starting on a cleanup as well (that can
come later).
Please consider for inclusion.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Received From Mark Salyzyn
The queue tracking is just not being used, not even for debugging. Information
about outstanding commands can be acquired from the scsi structures.
Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Received From Mark Salyzyn
A race condition existed that could result in a lost completion of a
command to the ppc based cards.
Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Received From Mark Salyzyn
Add the ability to adjust for unusual corner case failures. Both of
these additional module parameters deal with embedded, non-intel or
complicated system scenarios.
Aif_timeout can be increased past the default 2 minute timeout to drop
application registrations when a system has an unusually high event load
resulting from continuing management requests, or simultaneous builds,
or sluggish user space as a result of system load.
Startup_timeout can be increased past the default 3 minute timeout to
drop an adapter initialization for systems that have a very large number
of targets, or slow to spin-up targets, or a complicated set of array
configurations that extend the time for the firmware to declare that it
is operational. This timeout would only have an affect on non-intel
based systems, as the (more patient) BIOS would generally be where the
startup delay would be dealt with.
Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Received From Mark Salyzyn
Slight space and speed efficiency improvement.
Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Received From Mark Salyzyn
Since new commands to the card are quiesced, respect the changes in
the SCSI error path which dropped locking around the hba reset handler
and similarly drop the lock requirement in the driver's path.
Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
A couple write attributes in sas transport layer have a small
bug that prevents them from being written to. Those
attributes are the link_reset and write_reset. This is due
the store field being set to NULL.
Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
the user_scan() callback currently has the potential to identify the
wrong device in the presence of expanders. This is because it finds
the first device with a matching target_id, which might be an
expander. Fix this by making it look specifically for end devices.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
