Frans Pop wrote: > On Monday 08 September 2008, Frans Pop wrote: >> On Monday 08 September 2008, Mark Lord wrote: >>> Frans Pop wrote: >>>> So, IMO it is an improvement, but it is definitely not a fix for >>>> the regression. >>> With a new copy of hdparm, use "hdparm -Q1 /dev/sd?" >>> Does that fix your "regression" ? >> $ sudo hdparm -Q1 /dev/sda >> >> /dev/sda: >> setting queue_depth to 1 >> queue_depth = 1 >> >> Yes, that does result in the original behavior of the led. >> (Using version 8.9 of hdparm.) > > But that's not new information: we'd already determined some time ago that > disabling NCQ "fixed" the problem, both if it is done at runtime and when > it is disabled in the driver: > http://www.spinics.net/lists/linux-ide/msg25642.html > http://www.spinics.net/lists/linux-ide/msg25645.html Setting queue_depth to 1 is not disabling NCQ; it's NCQ enabled, no more than one command outstanding at a time. A queue depth of 0 disables NCQ completely. While I don't have the relevant hardware, this sounds like a hardware limitation, not a regression. I suspect that the LED is active whenever a command is outstanding; with NCQ allowed to queue more than 1 command at a time, Linux is keeping the drive fed with commands so that there are always outstanding commands, and thus the light never goes inactive during disk activity. As a result, you never see the LED intensity vary, as the drive never idles waiting for a new command, but is constantly processing commands as fast as it can. Allowing the drive to idle would get you the "flickering" you want, at the expense of the performance gain NCQ provides. -- I'm sure Saeed or Mark will correct me if I'm completely wrong, Simon Farnsworth -- 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
