Effectively reporting firmware errors

Including timestamps in the logs help significantly. This can be enabled by setting CONFIG_PRINTK_TIME to "y" directly or do it through the menu at Kernel Hacking -> Show timing information on printks .

Setting your driver's debug parameter to 0x43fff and capturing dmesg output is still the most effective way to capture useful information about firmware restarts. This is done by loading the driver with the "0x43fff" debug parameter.
For 3945 it is:

$ modprobe iwl3945 debug=0x43fff
or
$ insmod iwl3945 debug=0x43fff

For 4965 and up it is:

$ modprobe iwlagn debug=0x43fff
or
$ insmod iwlagn debug=0x43fff

When a microcode error is detected you will notice a title Microcode SW error detected followed by an Error Log Dump, followed by an Event Log Dump. The Event Log can be long, but please ensure that all of the data from both these dumps are included in your report. It's often helpful to have a lot of the dmesg output prior to the actual Restart, so we can see what the driver/system is trying to do (recent commands to the NIC, etc.).

Please attach longer logs to the bug report, these are easier to deal with than long logs included in a comment. If it's really long (i.e. bugzilla won't accept it), compress it with gzip.

The dmesg output also allows you to see the basic reason for the firmware error in the 3rd or 4th line following Microcode SW Error. The reason will have headers in the previous line like Desc, Time, etc. This reason actually should be the basis for creating new bug reports on bugzilla.org ... it will help keep things sorted out if you put that reason in the Summary.

Tips for creating new firmware bug report in bugzilla.org:

1) Select "firmware error" in the Component field.

2) Include reason (in 3rd or 4th line after "Microcode SW Error") in Summary field. Include just the all-caps word (e.g. FATAL_ERROR or SYSASSERT) and the value in the field found at the end of the line.