bbee wrote: >> Yeap, I have major issues with SDB FISes which contains spurious >> completions but most other spurious interrupts shouldn't be dangerous >> and I haven't seen spurious completions for quite some time, so I was >> thinking either removing the message or printing it only on SDB FIS >> containing spurious completions. >> >> But, Andrew Lyon *is* reporting spurious completions. Now I just wanna >> update those printks such that more info is reported only on spurious >> SDB FISes. > > That would certainly help verify that I'm having the exact same problem, > since Andrew didn't say anything about his drive going offline. Okay. [--snip--] > I reverted the patch and am waiting for the exception while running > "stress --io 2 --hdd 2". By past experience, it could take a while; I am > already seeing the spurious iterrupt messages though. Thanks, please keep me posted. >> Can you post the results of 'dmesg' and 'hdparm -I /dev/sdX'? > > Follows at end of message (md init snipped from dmesg for brevity). > >> Yeap, I'm definitely interested in resolving this problem. It's not >> likely but possible that the *controller* is responsible for spurious >> interrupts. > > Unfortunately I don't have any other model of SATA drive to test it > with, but Andrew by his dmesg seems to be using a different brand of drive. > ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > ata1.00: ATA-7, max UDMA/100, 586072368 sectors: LBA48 NCQ (depth 31/32) > ata1.00: ata1: dev 0 multi count 16 > ata1.00: configured for UDMA/100 > scsi 0:0:0:0: Direct-Access ATA Maxtor 6V300F0 VA11 PQ: 0 > ANSI: 5 Yeah, a different drive. I'll ask around. Thanks. -- tejun - 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
