nForce4 ADMA with NCQ: It's aliiiive..
in [Kernel]
|
Prev: [PATCH] [MTD] CHIPS: Support for SST 49LF040B flash chip
Next: Havee seeen vanquish Cuties gett fuccked in holees?
From: Prakash Punnoor on 7 Oct 2006 05:50 Am Samstag 07 Oktober 2006 10:08 schrieb Robert Hancock: > I've been working on the patch for sata_nv ADMA support for nForce4 that Nice! > make the default 1). I only enabled ADMA on those chipsets and not > MCP51, MCP55 or MCP61 since that was all that the original NVIDIA > version did. I assume there was a reason for this, though maybe not. Unfortunately it doesn't work for me on MCP51 if I change GENERIC to ADMA. So I wonder whether MCP51 has ADMA mode or what needs to be done to get NCQ working. :-( Cheers, -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V
From: Jeff Garzik on 7 Oct 2006 11:30 Robert Hancock wrote: > I've been working on the patch for sata_nv ADMA support for nForce4 that > Jeff Garzik has in a git branch. I've gotten it into a state where the > ADMA and NCQ features appear to be working with no obvious problems. > I've attached a patch against 2.6.18-mm2. > > The code was mostly in a working state for the non-NCQ case but there > were a number of heinous bugs that prevented NCQ from working, like in > the sg list to APRD conversion code and in the interrupt handler. > > This is still in quite an experimental state. It has survived system > boots into Fedora Core 5 and Bonnie++ benchmark runs without blowing up, > but there could still be bugs that could corrupt data, etc. so test with > caution. > > There is a module parameter adma_enabled which has to be set to 1 to > enable ADMA on CK804/MCP04 chipsets (either that or hack the code to > make the default 1). I only enabled ADMA on those chipsets and not > MCP51, MCP55 or MCP61 since that was all that the original NVIDIA > version did. I assume there was a reason for this, though maybe not. > Someone with one of these chipsets should probably try it out (replacing > the GENERIC type with CK804 in the PCI device table may be all it takes). Nice! Good work. > A few outstanding issues: > > -Error handling likely needs work. EH works well enough to get past > drive detection but that's likely about all. When I ran into errors > while debugging, it usually locked up the machine when trying to do a > soft reset. > > -Error handling is also noisy at the moment (it dumps a bunch of > controller state information). > > -Jeff will probably cringe at how I implemented the > bmdma_stop/start/status/setup functions. This kludge of toggling > ATA_FLAG_MMIO off for the call into libata was needed since this > controller is almost what libata calls ATA_FLAG_MMIO, but not quite (the > ATA taskfile registers are MMIO but the BMDMA registers are PIO). This > is also why I needed the patch to libata-sff.c to use the adapter's > bmdma_status function rather than hardcoded ata_bmdma_status. *shrug* I don't cringe if that's the most expedient way to do something. But I really don't think that is necessary. I will take a look at docs and see how things match up, when I am much more awake. Most likely you need to be using another set of registers, and be all MMIO, all the time. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 7 Oct 2006 12:00 Prakash Punnoor wrote: > Am Samstag 07 Oktober 2006 10:08 schrieb Robert Hancock: >> I've been working on the patch for sata_nv ADMA support for nForce4 that > > Nice! > >> make the default 1). I only enabled ADMA on those chipsets and not >> MCP51, MCP55 or MCP61 since that was all that the original NVIDIA >> version did. I assume there was a reason for this, though maybe not. > > Unfortunately it doesn't work for me on MCP51 if I change GENERIC to ADMA. So > I wonder whether MCP51 has ADMA mode or what needs to be done to get NCQ > working. :-( What happened when you tried it? It would be useful if you could change the #undef in these lines: 53 #undef ATA_DEBUG /* debugging output */ 54 #undef ATA_VERBOSE_DEBUG /* yet more debugging output */ in include/linux/libata.h to #define and rebuild and try it then, that will spew out a bunch more output and I can see if any reasonable looking values are showing up at all. I was capturing this output the crude way, booting with vga=6 to get a smaller font and taking a picture of the screen :-) Also, maybe post the lspci -v output from the SATA controller.. If that doesn't provide any insight, maybe the docs Jeff has provide the answer for whether or not the MCP5x/MCP61 controllers have the same interface as the CK804/MCP04.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr(a)nospamshaw.ca Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 7 Oct 2006 20:00 Jeff Garzik wrote: >> -Jeff will probably cringe at how I implemented the >> bmdma_stop/start/status/setup functions. This kludge of toggling >> ATA_FLAG_MMIO off for the call into libata was needed since this >> controller is almost what libata calls ATA_FLAG_MMIO, but not quite >> (the ATA taskfile registers are MMIO but the BMDMA registers are PIO). >> This is also why I needed the patch to libata-sff.c to use the >> adapter's bmdma_status function rather than hardcoded ata_bmdma_status. > > *shrug* I don't cringe if that's the most expedient way to do something. > > But I really don't think that is necessary. I will take a look at docs > and see how things match up, when I am much more awake. Most likely you > need to be using another set of registers, and be all MMIO, all the time. > > Jeff Hopefully that is the case, it would clean things up a bit.. I've cut another patch, this one against 2.6.18-mm3. I've fixed a couple of issues: -Error handling now pushes the port back into port-register mode so that the reset will actually work properly. -It seems there was a problem with the checks for deciding whether to scan the CPB list in the interrupt handler that occasionally caused interrupts to get lost and commands to time out (which unintentionally tested the EH fix above). I think this is fixed now. Signed-off-by: Robert Hancock <hancockr(a)shaw.ca> -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr(a)nospamshaw.ca Home Page: http://www.roberthancock.com/
From: Allen Martin on 10 Oct 2006 02:50
> > Unfortunately it doesn't work for me on MCP51 if I change > GENERIC to > > ADMA. So I wonder whether MCP51 has ADMA mode or what needs > to be done > > to get NCQ working. :-( > > What happened when you tried it? It would be useful if you > could change the #undef in these lines: > > 53 #undef ATA_DEBUG /* debugging output */ > 54 #undef ATA_VERBOSE_DEBUG /* yet more debugging output */ > > in include/linux/libata.h to #define and rebuild and try it > then, that will spew out a bunch more output and I can see if > any reasonable looking values are showing up at all. I was > capturing this output the crude way, booting with vga=6 to > get a smaller font and taking a picture of the screen :-) > Also, maybe post the lspci -v output from the SATA controller.. > > If that doesn't provide any insight, maybe the docs Jeff has > provide the answer for whether or not the MCP5x/MCP61 > controllers have the same interface as the CK804/MCP04.. No, only CK804 and MCP04 support ADMA. We'll be publishing some patches for NCQ support for MCP55/MCP61 soon. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |