headers
Giel van Schijndel | 1 Aug 2010 01:31
Picon
Favicon
Gravatar

Re: [PATCH 1/4] hwmon: f71882fg: Add support for the Fintek F71808E

On Wed, Mar 24, 2010 at 11:31:40 +0100, Hans de Goede wrote:
> On 03/24/2010 10:23, Giel van Schijndel wrote:
>> On Wed, Mar 24, 2010 at 09:25:08 +0100, Hans de Goede wrote:
>>> See comments inline.
>>>
>>> On 03/24/2010 12:12 AM, Giel van Schijndel wrote:
>>>> Allow device probing to recognise the Fintek F71808E.
>>>> 
>>>> Sysfs interface:
>>>>    * Fan/pwm control is the same as for F71889FG
>>>>    * Temperature and voltage sensor handling is largely the same as for
>>>>      the F71889FG
>>>>     - Has one temperature sensor less (doesn't have temp3)
>>>>     - Misses one voltage sensor (doesn't have V6, thus in6_input refers to
>>>>       what in7_input refers for F71889FG)
>>>> 
>>>> For the purpose of the sysfs interface fxxxx_in_temp_attr[] is split up
>>>> such that it can largely be reused.
>>>>---
>>>>   Documentation/hwmon/f71882fg |    4 ++
>>>>   drivers/hwmon/Kconfig        |    6 ++--
>>>>   drivers/hwmon/f71882fg.c     |   80 +++++++++++++++++++++++++++++++++++++----
>>>>   3 files changed, 79 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/hwmon/f71882fg.c b/drivers/hwmon/f71882fg.c
>>>> index 25e1cad..b290b87 100644
>>>> --- a/drivers/hwmon/f71882fg.c
>>>> +++ b/drivers/hwmon/f71882fg.c
>>>>  <at>  <at>  -1974,8 +2002,27  <at>  <at>  static int __devinit f71882fg_probe(struct platform_device *pdev)
>>>> ... snip ...
(Continue reading)

Permalink | Reply | 29 comments |
headers
Fernando Lopez-Lezcano | 1 Aug 2010 03:55
Picon

Re: 2.6.33.6-rt26: oops (network related?)

On Sat, 2010-07-31 at 12:01 -0700, Fernando Lopez-Lezcano wrote:
> On Thu, 2010-07-29 at 20:30 -0700, Fernando Lopez-Lezcano wrote:
> > Hi all...
> > This may not be rt related but here it goes anyway. It happened when I
> > tried to restart my iptables service (/sbin/service iptables start). I
> > think a day or two ago I had another network related hang, but it was a
> > complete hang (no clues left behind - power button to reset). 
> 
> Ok this one is rt related (apparently). The workstation (4 core, intel
> based) hang hard while a process was starting a daily backup but the
> logs captured the BUG:

One more observation, I repeatedly copied a couple of ISO images over
the network to the affected machine. No problem during the copy. BUT, it
hang completely when I tried to reboot it - while stopping the firewall
(I'm using shorewall), regretfully no trace was left behind. So
_something_ in the network stack is left is a bad state. I did see a
similar hang when stopping the iptables service in my laptop. 

This did not happen with the regular Fedora kernel (same test, no
problem). 

-- Fernando

> --------
> Jul 31 06:48:35 localhost kernel: ------------[ cut here ]------------
> Jul 31 06:48:35 localhost kernel: kernel BUG at kernel/rtmutex.c:808!
> Jul 31 06:48:35 localhost kernel: invalid opcode: 0000 [#1] PREEMPT SMP 
> Jul 31 06:48:35 localhost kernel: last sysfs
> file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric W. Biederman | 1 Aug 2010 04:42
Favicon

Re: [PATCH] x86,setup: add serial_console_port_base in boot_params

Yinghai Lu <yinghai <at> kernel.org> writes:

> On 07/31/2010 02:02 PM, H. Peter Anvin wrote:
>> On 07/31/2010 11:32 AM, Cyrill Gorcunov wrote:
>>>>
>>>> No, this is the internal part of the boot protocol, so it's not an issue.
>>>>
>>>
>>> Peter, I didn't mean any issue here, I meant that bootloaders don't know about
>>> this field yet and they will have to update own sources to pass port value
>>> at proper place of boot params. Or I miss something?
>>>
>> 
>> Boot loaders that use the 16-bit entry point are unaffected.
>> 
>> Boot loaders which use the 32-bit entry point but properly clears the
>> zero page simply will not have the feature.
>> 
>> Boot loaders which use the 32-bit entry point but doesn't clear the zero
>> page are broken.
>> 
> can you if this one is right for kexec path?

I am walking out the door, but this seems like nonsense to me.

The kexec console_serial option today is a debugging feature for
when you to debug the purgatory code.  Only once in a bluemoon
should it be useful, so I don't see why we would add it here.
The kexec purgatory is silent by default.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul E. McKenney | 1 Aug 2010 06:36
Picon

Re: Attempted summary of suspend-blockers LKML thread

On Sat, Jul 31, 2010 at 04:19:48PM -0400, Alan Stern wrote:
> On Sat, 31 Jul 2010, Paul E. McKenney wrote:
> 
> > Rushing in where angels fear to tread...
> > 
> > I had been quite happily ignoring the suspend-blockers controversy.
> > However, now that I have signed up for the Linaro project that involves
> > embedded battery-powered devices, I find that ignorance is no longer
> > bliss.  I have therefore reviewed much of the suspend-blocker/wakelock
> > material, but have not yet seen a clear exposition of the requirements
> > that suspend blockers are supposed to meet.  This email is a attempt
> > to present the requirements, based on my interpretation of the LKML
> > discussions.
> > 
> > Please note that I am not proposing a solution that meets these
> > requirements, nor am I attempting to judge the various proposed solutions.
> > In fact, I am not even trying to judge whether the requirements are
> > optimal, or even whether or not they make sense at all.  My only goal
> > at the moment is to improve my understanding of what the Android folks'
> > requirements are.  That said, I do include example mechanisms as needed to
> > clarify the meaning of the requirements.  This should not be interpreted
> > as a preference for any given example mechanism.
> > 
> > But first I am going to look at nomenclature, as it appears to me that
> > at least some of the flamage was due to conflicting definitions.  Following
> > that, the requirements, nice-to-haves, apparent non-requirements,
> > an example power-optimized applications, and finally a brief look
> > at other applications.
> > 
> > Donning the asbestos suit, the one with the tungsten pinstripes...
(Continue reading)

Permalink | Reply | 12 comments |
headers
Arjan van de Ven | 1 Aug 2010 06:52
Favicon

Re: Attempted summary of suspend-blockers LKML thread

On Sat, 31 Jul 2010 10:58:42 -0700
"Paul E. McKenney" <paulmck <at> linux.vnet.ibm.com> wrote:

> o	"Power-aware application" are applications that are permitted
> 	to acquire suspend blockers on Android.  Verion 8 of the
> 	suspend-blocker patch seems to use group permissions to
> determine which applications are classified as power aware.
> 
> 	More generally, power-aware applications seem to be those that
> 	have permission to exert some control over the system's
> 	power state.

I don't like the term "Power aware application". An application is well
behaved or it isn't. "aware" has nothing to do with it.

> 
> REQUIREMENTS
> 
> o	Reduce the system's power consumption in order to (1) extend
> 	battery life and (2) preserve state until AC power can be
> obtained.

AC power is not relevant in discussions around power: Applications MUST
behave well, AC or DC both. Just ask any data center operator on how
much they run on DC and if he cares about power consumption.
Conversely, most mobile usages (both phone, tablet or netbook) are "DC
only"....

 
> o	It is necessary to be able to use power-naive applications.
(Continue reading)

Permalink | Reply | 493 comments |
headers
David Miller | 1 Aug 2010 07:05
Favicon

Re: [PATCH] act_nat: the checksum of ICMP doesn't have pseudo header

From: Herbert Xu <herbert <at> gondor.apana.org.au>
Date: Fri, 30 Jul 2010 22:30:16 +0800

> On Fri, Jul 30, 2010 at 10:16:05PM +0800, Changli Gao wrote:
>> 
>> I know we need to update the ICMP checksum if we alter the payload(the
>> inner IP header here) of ICMP. But I doubt if the update is really
>> necessary if the checksum is partial, as the   checksum will be done
>> later(by ether skb_checksum_help() or NIC hardware). In fact, as there
>> isn't any pseudo header, the icmph->checksum should be always ZERO,
>> otherwise skb_checksum_help() or NIC will give the wrong checksums,
>> when the checksum is partial.
> 
> Actually you are right.  I suppose the only reason this has never
> shown up is because CHEKSUM_PARTIAL doesn't usually occur with
> forwarded packets.
> 
> Acked-by: Herbert Xu <herbert <at> gondor.apana.org.au>

Also applied, thanks.
Permalink | Reply | 0 comments |
headers
Hitoshi Mitake | 1 Aug 2010 07:36
Picon
Favicon

Re: [PATCH RFC] perf lock: Add new event "lock_acquired_waittime" for contention analysis

On 07/29/10 01:39, Frederic Weisbecker wrote:
 > On Sun, Jul 25, 2010 at 01:55:29AM +0900, Hitoshi Mitake wrote:
 >> Recording every lock events produces too large overhead
 >> both in CPU time and memory space.
 >> This overhead is a big problem which should be solved,
 >> but locks are important factor today.
 >>
 >> So I'd like to add a new lock event "lock_acquired_waittime"
 >> for contention analysis. lock_acquired() calculates time consumed
 >> for waiting the locks with held_lock->waittime_stamp set by
lock_contended().
 >> If this value is 0, no contention occured. If this value is not 0,
 >> there is occurence of contention.
 >> So I inserted the branch based on this value into lock_acquired().
 >> New lock_acquired() calls trace_lock_acquired() when waittime is 0,
 >> and calls trace_lock_acquired_waittime(), function for the new event,
 >> when waittime is not 0.
 >>
 >> The traditional event, lock_acquired, is too high frequency event.
 >> But the event lock_acquired_waittime is not so high frequency,
 >> so overhead produced by tracing this event is not so large.
 >>
 >> This is an example:
 >> | mitake <at> X201i:~/linux/.../tools/perf% ./perf bench sched messaging
 >> | # Running sched/messaging benchmark...
 >> | # 20 sender and receiver processes per group
 >> | # 10 groups == 400 processes run
 >> |
 >> |      Total time: 1.712 [sec]
 >> | mitake <at> X201i:~/linux/.../tools/perf% sudo ./perf record -R -f -m
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul E. McKenney | 1 Aug 2010 07:48
Picon

Re: Attempted summary of suspend-blockers LKML thread

On Sat, Jul 31, 2010 at 09:52:14PM -0700, Arjan van de Ven wrote:
> On Sat, 31 Jul 2010 10:58:42 -0700
> "Paul E. McKenney" <paulmck <at> linux.vnet.ibm.com> wrote:
> 
> > o	"Power-aware application" are applications that are permitted
> > 	to acquire suspend blockers on Android.  Verion 8 of the
> > 	suspend-blocker patch seems to use group permissions to
> > determine which applications are classified as power aware.
> > 
> > 	More generally, power-aware applications seem to be those that
> > 	have permission to exert some control over the system's
> > 	power state.
> 
> I don't like the term "Power aware application". An application is well
> behaved or it isn't. "aware" has nothing to do with it.

Applications are often complex enough to be aware of some things, naive
about others, well behaved in some ways, and ill-behaved in others.
This has been the case for some decades now, so it should not come as
a surprise.

I am of course open to suggestions for alternatives to the term "power
aware application", but most definitely not to obfuscating the difference
between power awareness (or whatever name one wishes to call it) and
the overall quality of the application, whatever "quality" might mean
in a given context.

> > REQUIREMENTS
> > 
> > o	Reduce the system's power consumption in order to (1) extend
(Continue reading)

Permalink | Reply | 491 comments |
headers
Arjan van de Ven | 1 Aug 2010 08:01
Favicon

Re: Attempted summary of suspend-blockers LKML thread

On Sat, 31 Jul 2010 22:48:16 -0700
"Paul E. McKenney" <paulmck <at> linux.vnet.ibm.com> wrote:

> On Sat, Jul 31, 2010 at 09:52:14PM -0700, Arjan van de Ven wrote:
> > On Sat, 31 Jul 2010 10:58:42 -0700
> > "Paul E. McKenney" <paulmck <at> linux.vnet.ibm.com> wrote:
> > 
> > > o	"Power-aware application" are applications that are
> > > permitted to acquire suspend blockers on Android.  Verion 8 of the
> > > 	suspend-blocker patch seems to use group permissions to
> > > determine which applications are classified as power aware.
> > > 
> > > 	More generally, power-aware applications seem to be those
> > > that have permission to exert some control over the system's
> > > 	power state.
> > 
> > I don't like the term "Power aware application". An application is
> > well behaved or it isn't. "aware" has nothing to do with it.
> 
> Applications are often complex enough to be aware of some things,
> naive about others, well behaved in some ways, and ill-behaved in
> others. This has been the case for some decades now, so it should not
> come as a surprise.

I do not like the term "aware". At all.
It implies "awareness", and implies it does things based on the power
circumstances.

It's about *behaving well*. (not polling, not having activity when
there is nothing to do etc etc). Not about being aware that power
(Continue reading)

Permalink | Reply | 473 comments |
headers
Vasiliy Kulikov | 1 Aug 2010 08:14
Picon

Re: [PATCH 1/7] 68328serial: check return value of copy_*_user() instead of access_ok()

On Sat, Jul 31, 2010 at 21:09 +0200, Dan Carpenter wrote:
> On Sat, Jul 31, 2010 at 09:38:00PM +0400, Kulikov Vasiliy wrote:
> > -						sizeof(struct m68k_serial)))
> > -				return -EFAULT;
> > -			copy_to_user((struct m68k_serial *) arg,
> > +			return copy_to_user((struct m68k_serial *) arg,
> >  				    info, sizeof(struct m68k_serial));
> 
> We should return if -EFAULT copy_to_user() failes here.

Right, I was looking for this bug and made it myself :)
Thank you.

> 
> > -			return 0;
> > -			
> >  		default:
> >  			return -ENOIOCTLCMD;
> >  		}
> 
> Smatch would have caught that but I don't have a cross compile
> environment set up.
> 
> regards,
> dan carpenter
Permalink | Reply | 0 comments |

Gmane