linux-kernel - Re: [PATCH] intel_ips: quieten "power or thermal limit exceeded" messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C791ABA.9070005@cesarb.net>
Date:	Sat, 28 Aug 2010 11:18:34 -0300
From:	Cesar Eduardo Barros <cesarb@...arb.net>
To:	Joe Perches <joe@...ches.com>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Matthew Garrett <mjg@...hat.com>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] intel_ips: quieten "power or thermal limit exceeded"
 messages

Em 28-08-2010 10:29, Joe Perches escreveu:
> On Sat, 2010-08-28 at 09:52 -0300, Cesar Eduardo Barros wrote:
>> Em 28-08-2010 08:15, Joe Perches escreveu:
>>>> I will try to enable dev_dbg() later and see what it prints.
>>> or add:
> []
>> Here it is:
>>
>> intel ips 0000:00:1f.6: Warning: CPU TDP doesn't match expected value
>> (found 25, expected 35)
>> intel ips 0000:00:1f.6: PCI INT C ->  GSI 18 (level, low) ->  IRQ 18
>> intel ips 0000:00:1f.6: show_turbo_limits:ips_probe cte:1 gte:1 cpt:0
>> mpl:65535 mtl:65535 mpl:65535
>
> So ips->core_power_limit is still 0.
>
> Is it bad bios or driver?
>
> I expect the bios/hw is faulty but fingers are easy to point.
>
> Your choice on how to minimize your current logging problem.
>
> Changing the message level to dev_dbg probably isn't the
> right thing to do overall, but it may suit you right now.

The solution here probably is not less logging. The best solution IMO 
would be to do some sanity checking when loading the module, and if the 
values do not make sense, print something to the log and return -ENODEV.

I expect that, when it works as it should, the first read while loading 
the module already returns sane values, so a sanity check there should 
not have many false positives. OTOH, it is best to not load the module 
when you think things are strange.

-- 
Cesar Eduardo Barros
cesarb@...arb.net
cesar.barros@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/