On Wed, Dec 21, 2011 at 1:05 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >> Dan Williams (2): >> >> isci: cleanup oem parameter and recipe handling >> > >> > This isn't a bug fix >> >> Certainly not, but I wanted git blame on the subsequent settings to >> point to the commit where the value actually changed before adding >> more line wrapped register writes. > > Anyone who uses git blame knows how to cope with that. If we adopted > that principle; we'd have tons of whitespace and code motion type > changes in the stable trees, which isn't a good precedent. Ok, I would not have submitted a cleanup like this to -stable... and that's the litmus test I should use for queuing (or not as it were) late -rc changes. >> >> Dave Jiang (1): >> >> isci: oem parameter format v1.1 (ssc select) >> >> Jeff Skirvin (3): >> >> isci: update afe (analog-front-end) recipe for C1 >> >> isci: oem parameter format v1.3 (cable select) >> > >> > New silicon support is an enhancement not a bug fix (last three patches) >> >> I hate being put between a platform definition revision and a -rc window. >> >> 3.2 has an opportunity to ship with support for these settings that >> affect link stability and meet signal integrity targets so I felt it >> was worth calling these patches out separately from the wider updates >> targeted for 3.3. > > The process for updates is that they go into the next merge window (i.e. > for the 3.3 kernel). If there's a case for adding this to 3.2 or > earlier kernels, then the distros will do it. 3.3 material it is. >> >> Maciej Trela (1): >> >> isci: remove unused 'isci_tmf->device' field >> > >> > This isn't a bug fix. >> >> Yeah, "kernel crash" made me throw it in the 'fixes' pile, but since >> it is hidden behind enabling a dev_dbg() statement it can certainly be >> deferred. > > What kernel crash? The changelog doesn't mention anything about it. NULL de-reference of ->device. "As the field was never set, isci_print_tmf() using 'isci_tmf->device' sometimes causes a kernel crash if the dev_dbg() statement is enabled." >> >> Marcin Tomczak (1): >> >> isci: performance-fix, shorten default "no outbound task" timeout >> > >> > I don't quite see from the description how this is a performance >> > enhancement? It does nothing in the single initiator case, right? >> >> This rate limits the link arbitration for how often the hardware >> switches to a different remote-node-context. At higher queue depths >> we would see IOPs performance drop off rather than saturate, adjusting >> this timeout corrected that condition. > > I think I still don't understand what this is. All outbound links have > to switch context rapidly in a multi-target environment with switches on > the order of microseconds ... where exactly is this 10s timeout you > reduce to 2s triggered? Not sure what gave the 1s unit impression, but now that I look the units of the module parameter are wrong. This value is in 256ns increments (not 1us) so we are changing the target context switch rate from 5us to 512ns. This value is put to the phy's link layer control register in sci_phy_link_layer_initialization(). -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
