No functional changes, just logging more information when uCode crash, also
change change the format.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The current "huge" command handling is a bit
confusing, and very limited since only one
command may be huge at a time. Additionally,
we often copy data around quite pointlessly
since we could instead map the existing scan
buffer for example and use it directly.
This patch makes that possible. The first
change is that multiple buffers may be given
to each command (this change was prepared
earlier so callsites don't need to change).
Each of those can be mapped attached to a TB
in the TFD, and the command header can use a
TB (the first one) in the TFD as well.
Doing this allows getting rid of huge commands
in favour of mapping existing buffers. The
beacon transmission is also optimised to not
copy the SKB at all but use multiple TBs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The TX tracing code copies with the wrong length,
which will typically copy too little data. Fix
this by using the correct length variable.
Cc: stable@kernel.org [2.6.32+]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwl-devtrace.h is used to declare and define trace points and
including iwl-dev.h from the file, which in turn includes other
generic headers, can lead to problems like generating duplicate copies
of generic trace points depending on the order of includes. Don't
include iwl-dev.h from iwl-devtrace.h but include it from its users -
iwl-io.h and iwl-devtrace.c.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Intel Linux Wireless <ilw@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
In order to help uCode debugging, adding the capability to provide
continuous uCode event logging function.
uCode events is located in round-robin event queue and filled by uCode,
by enable continuous event logging, driver check the write pointer
and log the newly added events in iwl_bg_ucode_trace() timer function.
There is still possibility of missing events if event queue being
wrapped before next event dump; but with this capability, we can have
much better understanding of the uCode behavior during runtime; it can
help to debug the uCode related issues.
Methods to enable/disable the continuous event log:
step 1: enable ucode trace timer
"echo 1 >
/sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
step 2: start ftrace
sudo ./trace-cmd record -e iwlwifi_ucode:* sleep 1d
step 3: stop ftrace
sudo ./trace-cmd report trace.dat
step 4: disable ucode trace timer
"echo 0 >
/sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing"
use "ucode_tracing" debugfs file to display number of event
queue wrapped when driver attempt the continuous event logging. If event
queue being wrapped more than once when driver has opportunity to log
the event; it indicated there are events missing in the event log trace.
This continuous event log function only available for 4965 and newer
NICs.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since IO tracing is usually not needed and
generates a lot of data, separate it into
its own trace system so that we can always
enable iwlwifi:* and not have to worry about
getting too much data. If IO tracing is then
really needed we can enable iwlwifi_io:* in
addition and get that data.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To support byte writes to CSR_INT_COALESCING and CSR_INT_PERIODIC registers,
add iwl_write8(), including debug/trace support.
Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to have an easier way to debug issues, create
trace events (using the ftrace framework) that will
allow us to follow exactly what the driver is doing
with the device.
The text format isn't all that useful, but the binary
format can also be obtained easily via debugfs and
then analysed on the fly or offline with debugging
tools.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
