Giel van Schijndel | 1 Aug 01:31 2010
Picon

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)

Benjamin Herrenschmidt | 1 Aug 02:27 2010

Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections

On Sat, 2010-07-31 at 12:55 -0700, Greg KH wrote:
> On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote:
> > > This set of patches de-couples the idea that there is a single
> > > directory in sysfs for each memory section.  The intent of the
> > > patches is to reduce the number of sysfs directories created to
> > > resolve a boot-time performance issue.  On very large systems
> > > boot time are getting very long (as seen on powerpc hardware)
> > > due to the enormous number of sysfs directories being created.
> > > On a system with 1 TB of memory we create ~63,000 directories.
> > > For even larger systems boot times are being measured in hours.
> > 
> > Greg, Kame, how do we proceed with these ? I'm happy to put them in
> > powerpc.git with appropriate acks or will you take them ?
> 
> I thought there would be at least one more round of these patches based
> on the review comments, right?

Yes, but I was nontheless inquiring whether I should pick them up after
said repost :-)

> I'll be glad to take them when everyone agrees with them.

Ok, good, one less thing to worry about in powerpc patchwork :-)

Cheers,
Ben.

> thanks,
> 
(Continue reading)

Fernando Lopez-Lezcano | 1 Aug 03:55 2010
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)

Yinghai Lu | 1 Aug 03:53 2010

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

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?

Thanks

Yinghai

[PATCH] kexec-tools: pass serial console base for early console in kernel

when kexec is used with "console_serial", set serial_console_port_base in boot_params.

Signed-off-by: Yinghai Lu <yinghai@...>
(Continue reading)

Eric W. Biederman | 1 Aug 04:42 2010

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)

FUJITA Tomonori | 1 Aug 05:03 2010
Picon

Re: [PATCH] swiotlb: enlarge iotlb buffer on demand

On Fri, 30 Jul 2010 21:07:06 -0400
Konrad Rzeszutek Wilk <konrad <at> kernel.org> wrote:

> I took your patch and was trying to fit it over the
> stable/swiotlb-0.8.4 branch and when I did so a found couple of things..
> 
> 
> > >  <at>  <at>  -215,14 +222,14  <at>  <at>  swiotlb_late_init_with_default_size(size_t default_size)
> > >  	bytes = io_tlb_nslabs << IO_TLB_SHIFT;
> 
> You should also initialize the __io_tlb_start array first:

Yeah, I know. As I wrote, this patchset breaks IA64.

I really merge to swiotlb's two memory allocator mechanisms
(swiotlb_init_with_default_size and
swiotlb_late_init_with_default_size). I need to look at the x86 memory
boot code after memblock surgery finishes.

And as you know, I've not fixed the error path and swiotlb_free. I'll
do later if people are not against swiotlb dynamic allocation.

Thanks,
Paul E. McKenney | 1 Aug 06:36 2010
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)

Paul E. McKenney | 1 Aug 06:46 2010
Picon

Re: [PATCH] drivers/acpi: call rcu_read_unlock in default case

On Sat, Jul 31, 2010 at 10:35:28PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia <at> diku.dk>
> 
> Adjust the default case so that it benefits from the call to rcu_read_unlock.
> 
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // <smpl>
>  <at> rcu <at> 
> position p1;
>  <at>  <at> 
> 
> rcu_read_lock <at> p1();
> ...
> rcu_read_unlock();
> 
>  <at>  <at> 
> position rcu.p1;
>  <at>  <at> 
> 
> *rcu_read_lock <at> p1();
> ... when != rcu_read_unlock();
> // </smpl>

I don't claim to understand the SmPL above, but I do like the patch.

Reviewed-by: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>

> Signed-off-by: Julia Lawall <julia <at> diku.dk>
(Continue reading)

Arjan van de Ven | 1 Aug 06:52 2010

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)

David Miller | 1 Aug 07:05 2010
Picon

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.


Gmane