On Mon, Aug 17, 2009 at 10:39 PM, Grant Grundler<grundler@xxxxxxxxxx> wrote: > On Mon, Aug 17, 2009 at 3:30 PM, Chris K<kayex@xxxxxxxxxx> wrote: >>... >>>>> > I have a Silicone Image 3132 chipset (PCI-E 2-port eSATA controller >>>>> > card) and a Sans Digital TRM4-B 4x hard drive enclosure >>> >>> Which PMP is in the TRM4-B HDD enclosure? >> >> After opening it up, it looks to be a Silicone Image 3726 chip. > > Ok ...just some questions to pull a bit more info. Still no idea what is wrong. > > Can you confirm the OS is seeing as a 3726? > Add a printk to dump SATA_PMP_GSCR_PROD_ID to the console > similar to how it's done in sata_pmp_revalidate_quick(). Or if dev->gscr[] > is already valid, printk dev->gscr[SATA_PMP_GSCR_PROD_ID]. This > assumesyou know how to build/install a kernel from a source tree. > Tell me if that's a bad assumption. :) How about generous assumption ;-) Could you elaborate on the steps for this? I should be able to figure it out with a bit more info on the process. > > ISTR some very early 3726 devices reported themselves as 4726 or > something like that. > This can affect which sata_pmp_quirks() are applied. I noticed this line in the dmesg, does this confirm if it's reporting the right model properly? "ata7.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9" > > BTW, the full dmesg output attached to the original mail never made it > to linux-ide mailing list...can you attach or post it someplace public? Yes, you can find my dmesg @ http://pastebin.com/f50585886 Not sure if you saw this part before too - This is the output I get on the screen during boot: [59719.989422] ata7: irq_stat 0x01100010, PHY RDY changed [59719.989477] ata7: SError: { 10B8B } [59722.781043] ata7: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen [59722.781112] ata7: irq_stat 0x00b40090, PHY RDY changed [59791.300259] ata7.15: failed to write PMP_FEAT_EN (Emask=0x40) [59791.300324] ata7: failed to recover PMP after 5 tries, giving up [59791.300323] ata7: exception Emask 0x3 SAct 0x0 SErr 0x0 action 0x6 frozen t4 [59791.300483] ata7: irq_stat 0x00060002, device error via D2H FIS > >> There's a sticker on the circuit board with "BIOS 1.0114" > > Should be good. 1.0114 firmware has one problem I can't talk about now > (NDAs, etc) and is unlikely to be related to this problem. > > > > .. >>> My guess is the LEDs going on and off are caused by the PMP getting reset >>> and not the Host OS "scanning". Are all the LEDs going on or off at >>> the same time? >>> Can you describe the on/off sequence of the LEDs? >>> >> >> Sure. The Power and "HOST" LEDs both light up, followed by LED "1" >> which is orange very briefly, green, orange briefly, green stays lit, > > How long between LED 1 and LED 2? > Is the sequence different if you power off the TRM4-B and power it > on again before rebooting the host machine? > LED 1 takes about 2-3 seconds.. the other LEDs are lit very quickly one after another. > If CONFIG_PRINTK_TIME=y, the dmesg output should let me figure this out. > This seems to be enabled already with my current kernel. > I'm expecting some sort of "spin up delay" to take effect but offhand > don't know the code path or if it will matter for this problem. > >> LED "2" orange very briefly, green stays lit, LED "3" orange very >> briefly, green stays lit, LED "4" orange very briefly, green stays lit >> - at this point all LEDs are on. > > Ok - this does sound like ports behind the PMPs are being scanned. > >> Shortly after all LEDs turn off >> together and the process repeats itself about 5 times. > > Can you add debug code to dump how many ports the PMP claims to have? > I'm wondering if a "ghost port" (magic "port" which doesn't have a SATA link but > some magic registers instead) is discovered/reported. > I can sure try! What should I do to enable this? Thanks, Chris. >> After it >> finishes it keeps Power, HOST and "1" lit up and then I receive the >> error messages. > > I suspect the PMP probe code sets up the link before exiting the error > handling loop. This would leave the link 1 (port 0 on PMP) on. > > thanks, > grant > >> >>> I'm hoping the would tell us more about where in the discovery process >>> it's failing. >>> I don't even have a good guess what the problem might be. >>> >>> hth, >>> grant >>> >> >> Haha, I know the feeling. Ran out of ideas a long time ago :-). Let >> me know if there's anything else you'd like me to try or any further >> info you require. >> >> Thanks. >> >> Chris. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
