Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Driver temperature threshold met warning still occur with --gpu-temp-disable switch #1757

Closed
mastercracker1 opened this issue Nov 3, 2018 · 8 comments

Comments

@mastercracker1
Copy link

mastercracker1 commented Nov 3, 2018

Like the title says even if I have the --gpu-temp-disable switch on my attack, I get the constant "Driver temperature threshold met warning...". That was not happening on the 4.2 version and it was the desired state.

EDIT: I forgot to mention a couple of key things. It's running under Windows 7 64 bit with Nvidia cards. I am also using the -S switch which was not in the previous version.

@jsteube
Copy link
Member

jsteube commented Nov 4, 2018

Are you sure that this is really a bug? The "Driver temperature threshold met warning..." message was always displayed (also in 4.2) even if --gpu-temp-disable was specified. That's a wanted behaviour.

Maybe the use of -S causes the GPU to create more heat (because of an eventual higher GPU utilization). In that case everything works as expected. Please verify.

@mastercracker1
Copy link
Author

Not in my case. Version 4.2.1 does not display any information about the GPU temps when --gpu-temp-disable is activated:
image
Here's what I get with 5.0.0:
image
The definition of --gpu-temp-disable in the help is "Disable temperature and fanspeed reads and triggers".

@mastercracker1
Copy link
Author

mastercracker1 commented Nov 5, 2018

I did not include it but when the temperature of the GPU #3 goes above 80°C, it starts adding yellow lines with the Driver temperature threshold met... message (in v5.0.0 only). The information from the status display quickly become out of sight and you see only lines of the warning message. I have MSI afterburner running in the background that keeps charge in throttling the card when it goes above 80°C. Without it, it would go way above 80°C. That's constant for both hashcat version so it's not an effect of a higher utilization of the card.

@philsmd
Copy link
Member

philsmd commented Nov 6, 2018

This "new behaviour" was introduced with this PR #1673 .

I think we should first think about what is the correct behaviour and afterwards try to handle it accordingly.
First, we have 2 options:
--gpu-temp-disable
--gpu-temp-abort

As far as I know, before we merged the PR mentioned above all fan and temp stuff was disabled with --gpu-temp-disable (also warnings/errors) etc.
The above PR changes this behaviour slightly and also allows fan/temp reads even if --gpu-temp-disable was specified.
According to the description for --gpu-temp-disable ("Disable temperature and fanspeed reads and triggers") the old behaviour could be seen as more accurate/correct.
Also note that we have no option for fan, therefore it's always either fan & speed... or none (this would be also a little bit difficult to change because we only have 1 line for them in the status screen).

The question now is: should --gpu-temp-disable only affect the monitoring of the temp and if needed aborting hashcat.... or should it affect everything (as it did before the PR, i.e. also reading/displaying the fan speed and temperature)?

It's quite easy to come up with a fix, but I think the fix that @mastercracker1 wants is to basically revert the above mentioned PR (with maybe some further changes).

I think that we should make hashcat behave according to the --gpu-temp-disable description (or if we decide otherwise we need to change this description too). What do you think ?

It would be great if @RAN1 could also join the discussion to see if we can come up with a solution we all are happy with.

@mastercracker1
Copy link
Author

mastercracker1 commented Nov 6, 2018

I am definitely not against seeing the GPU temps all the time. It's just the continuous stream of lines saying "Driver temperature threshold met..." that is annoying. There I can think of 2 options but I don't know if they are implementable. 1) Instead of having the "Driver temperature..." message. Change the color of the line showing the temperature (or the temperature value only) to a different color (yellow or red). 2) When the temperature is reached, push the whole status display and the warning line. I think the first option would be the best or I am open to other suggestions. Worst case scenario revert to old behavior.

@jsteube
Copy link
Member

jsteube commented Nov 6, 2018

I tend to agree with @philsmd to revert the changes (not really a git revert but restore the behavior as it was before the PR), but do an additional change.

Instead of calling the parameter --gpu-temp-disable and --gpu-temp-abort we should rename them to --hwmon-disable and --hwmon-temp-abort. Note that even if there's no temperature reading for CPU today it doesn't mean we will never have it in the future.

It would be nice to have @RAN1 to comment in detail the reason for the changes. But as we want to release a bug-fix release soon we should not wait too long in case @RAN1 does not respond and just to the changes as discussed.

@jsteube jsteube closed this as completed in 2aff01b Nov 9, 2018
@jsteube
Copy link
Member

jsteube commented Nov 9, 2018

Since there was no response I did the modifications here: 2aff01b

New beta is up on https://hashcat.net/beta/

Thanks for reporting!

@RAN1
Copy link
Contributor

RAN1 commented Nov 10, 2018

Hi all, sorry about the late reply.

The main reason for the PR was just that the behavior didn't match the flag name. I forgot about the help description, and I didn't notice that the throttle warnings would be set off when temperature abort isn't set.

The only other reason was a cosmetic issue with hwmon-less systems, where the hwmon and temp abort flags would prevent the hwmon-not-detected message from displaying. However it's no longer a problem so it doesn't have any significance here.

The most recent commit is probably the best way to handle it anyways, again sorry for not seeing this earlier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants