headers
Jin Dongming | 1 Nov 2010 01:04

Re: [PATCH 2/3] [x86, next] Add mce_ser interface in /sys/kernel/debug/mce/ for test

(2010/10/29 17:06), Andi Kleen wrote:
> On Fri, Oct 29, 2010 at 01:42:09PM +0900, Jin Dongming wrote:
>> If we want to test the part of mce handler for SRAO and SRAR,  we need to
>> have a test machine whose CPU supports MCG_SER_P. If we don't have such
>> machine, we can not test the part of mce handler for SRAO and SRAR.
>>
>> With this interface we can test the part of mce handler for SRAO and SRAR
>> by setting mce_ser 1 on the machine which does not support MCG_SER_P.
>>
>> Usage:
>>         if val == 1 or val == 0
>>            Set val to mce_ser.
>>         else
>>            Ser the original value to mce_ser.
>>
>> Note:
>>     Please don't use mce_ser interface except mce test.
>>     Because when the real mce exception happened, the unsuitable set
>>     with this interface maybe change the real process of mce handler and
>>     lead to a different result.
> 
> Basic idea is good (I have been using a similar patch for quite some time).
> My patch was a little bit simpler though, not bothering with org_ser:
> 
Yes, it is.

But if you set mce_ser with mca_recovery_set(), 
the original value of mce_ser will be changed, is it right?

If a new guy try to test mce with the test machine, he/she may be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jin Dongming | 1 Nov 2010 01:07

Re: [PATCH 3/3] [x86, next] Add mce_sys_info interface for debug.

Hi, Andi

Thanks for your review.
I will cancel this patch.

But I suggested there is such kind of tool for mce test.
It really costs too much time to confirm them one by one.

Best Regards,
Jin Dongming

(2010/10/29 17:10), Andi Kleen wrote:
> On Fri, Oct 29, 2010 at 01:42:23PM +0900, Jin Dongming wrote:
>> Add mce_sys_info interface for testing mce.
>>
>> Following is the reason why the interface is needed:
>>   1. Sometimes before testing mce, we want to know the basic
>>      information of mce on the test machine. Though there are
>>      some provided interfaces, there are some kernel variables
>>      which could not be known still.
> 
> That doesn't make sense to me. AFAIK everything is either available
> in sysfs or printed in the kernel log or can be known by knowing 
> the hardware.
> 
>>   2. When we inject mce data to test mce, the value of some
>>      interfaces may be changed. It is hard for everybody to confirm
>>      all the information of mce on the system.
>>
>> This interface could help us know what has happened and make mce test
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jin Dongming | 1 Nov 2010 01:11

Re: [PATCH 3/3] [x86, next] Add mce_sys_info interface for debug.

Hi, Borislav Petkov

Thanks for your review. Because this patch will be canceled, I could not
update it as your comment. But I will do other patches as your comment.

Thanks again.

Best Regards,
Jin Dongming

(2010/10/29 16:24), Borislav Petkov wrote:
> On Fri, Oct 29, 2010 at 01:42:23PM +0900, Jin Dongming wrote:
>> Add mce_sys_info interface for testing mce.
>>
>> Following is the reason why the interface is needed:
>>   1. Sometimes before testing mce, we want to know the basic
>>      information of mce on the test machine. Though there are
>>      some provided interfaces, there are some kernel variables
>>      which could not be known still.
>>   2. When we inject mce data to test mce, the value of some
>>      interfaces may be changed. It is hard for everybody to confirm
>>      all the information of mce on the system.
>>
>> This interface could help us know what has happened and make mce test
>> become easier.
>>
>> The content of mce_sys_info will be like following:
>>
>>   MCE status:                      Original/(Current) Value
>>       mce_disabled:                N
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Nov 2010 01:46

Re: [PATCH] Optimize relay_alloc_page_array() slightly by using vzalloc rather than vmalloc and memset

On Sun, 31 Oct 2010 14:39:14 -0400 Mathieu Desnoyers <mathieu.desnoyers <at> polymtl.ca> wrote:

> * Jesper Juhl (jj <at> chaosbits.net) wrote:
> > On Sat, 30 Oct 2010, Mathieu Desnoyers wrote:
> > 
> > > * Jesper Juhl (jj <at> chaosbits.net) wrote:
> > > > Hi,
> > > > 
> > > > We can optimize kernel/relay.c::relay_alloc_page_array() slightly by using 
> > > > vzalloc. The patch makes these changes:
> > > > 
> > > >  - use vzalloc instead of vmalloc+memset.
> > > >  - remove redundant local variable 'array'.
> > > >  - declare local 'pa_size' as const.
> > > 
> > > Hrm ? How does declaring a local variable as const helps the compiler in
> > > any way ?
> > > 
> > 
> > Hmm, probably not very much in this case (but it doesn't hurt either ;) - 
> > actually, removing the const yielded the exact same result, so it's 
> > "not at all" in this case). 
> > That bit came from my "build-in" tendency to declare stuff const when it 
> > obviously doesn't change/nor should. It's a habbit..
> 
> Which looks to me like a misunderstanding of the C99 standard. What you
> do is:
> 
> static struct page **relay_alloc_page_array(unsigned int n_pages)
> {
(Continue reading)

Permalink | Reply | 4 comments |
headers
Takuya Yoshikawa | 1 Nov 2010 01:49
Picon

Re: [PATCH] KVM x86: remove memset, use vzalloc and don't assign the same value to a variable twice

(2010/10/31 3:28), Jesper Juhl wrote:
> Hi,
>
> We can improve kvm_vm_ioctl_get_dirty_log() slightly by using vzalloc()
> rather than first allocating and then manually zero the memory with
> memset(). Also, while I was looking at this I noticed that we assign

I personally prefer this new vzalloc() to vmalloc() + memset().

Just from my interest, is there real performance difference not just
the cleanup effect?  If so, we'd better do this for other places too.

> -ENOMEM to the 'r' variable twice even though none of the code inbetween
> the two assignments can change 'r', so I removed the second assignment.
>
> Patch has been compile tested only.
>
> Please consider merging and please CC me on all replies as I'm not
> subscribed to the kvm mailing list.
>
>
> Signed-off-by: Jesper Juhl<jj <at> chaosbits.net>
> ---
>   x86.c |    4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 2288ad8..29f9c0a 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eli Billauer | 1 Nov 2010 02:12
Picon

Re: open() on /dev/tty takes 30 seconds on 2.6.36

Let me start with the headline: It's close() of a ttySx that takes 30 
seconds, during which the big TTY lock is held. Now to details.

Arnd Bergmann wrote:

> So modem-manager is the process you need to look at, as it holds the
> BTM, probably for a long time. It should not do that. First you should
> verify that when you don't have modem-manager running, the problem goes
> away. This may indeed be related to the misdetection of a serial port.
>   
That test is built-in: When modem-manager stops poking around, 
everything becomes fine again.
> The other thing to check is what modem-manager is actually doing. You can
> find out by looking at /proc/≤pid>/stack, where <pid> is the pid of the
> modem-manager process, 1835 in your example.
>   
OK, so this is what I did eventually: I ran strace on sshd and 
modem-manager, and I also added printk's to tell me when tty_lock() is 
invoked, when it actually got the lock, and when tty_unlock() is 
invoked. Pretty messy, and still.

Let's start with sshd's strace. We have a
01:06:20.152787 open("/dev/tty", O_RDWR|O_NOCTTY) = -1 ENXIO (No such 
device or address) <30.008153>

And this is what we have in /var/log/messages:

Nov  1 01:06:20 ocho modem-manager: (ttyS2) closing serial device...
Nov  1 01:06:20 ocho kernel: tty_lock() called
Nov  1 01:06:20 ocho kernel: tty_lock() got lock
(Continue reading)

Permalink | Reply | 5 comments |
headers
Larry Finger | 1 Nov 2010 02:46
Favicon

2.6.36-gitX spams logs with "hub 4-0:1.0: unable to enumerate USB device on port 5" messages

With the current mainline pull (get describe shows v2.6.36-9871-g3985c7c), my
logs are spammed with

[  101.308220] hub 4-0:1.0: unable to enumerate USB device on port 5
[  101.548357] hub 2-0:1.0: unable to enumerate USB device on port 5
[  101.760094] hub 4-0:1.0: unable to enumerate USB device on port 5
[  102.000128] hub 2-0:1.0: unable to enumerate USB device on port 5
[  102.212187] hub 4-0:1.0: unable to enumerate USB device on port 5
[  102.452196] hub 2-0:1.0: unable to enumerate USB device on port 5
[  102.664131] hub 4-0:1.0: unable to enumerate USB device on port 5

The USB devices on my system are

finger <at> larrylap:~/wireless-testing> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 003: ID 04f2:b016 Chicony Electronics Co., Ltd VGA 30fps UVC Webcam
Bus 001 Device 004: ID 07d1:3300 D-Link System
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I had this problem in the past when ohci_hcd was being loaded before ehci_hcd,
but that is not the case now as is shown by lsmod:

mbcache                 7798  1 ext3
ohci_hcd               22322  0
sd_mod                 29184  4
ehci_hcd               37829  0
usbcore               158887  4 r8712u,ohci_hcd,ehci_hcd
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Whitcroft | 1 Nov 2010 05:10
Favicon

Re: New 2.6.36 checkpatch complaints about leading whitespace

On Sat, Oct 30, 2010 at 11:35:22AM +0200, Bart Van Assche wrote:
> Hello Andy,
> 
> Apparently the checkpatch.pl script as included in 2.6.36 complains if
> continued lines start with whitespace. An example:
> 
> [ ... ]
> +#if defined(MACRO_NAME_1) || defined(MACRO_NAME_2) \
> +  || defined(MACRO_NAME_3)
> [ ... ]
> 
> checkpatch.pl reports the following warning for the above patch excerpt:
> 
> WARNING: please, no space for starting a line,
>                                 excluding comments
> 
> Is that a feature or an unintended side effect of recent checkpatch changes ?

My personal expectation would be for that second line to be indented
with a tab.  But I might be convinced otherwise?

-apw
Permalink | Reply | 1 comment |
headers
Grant Likely | 1 Nov 2010 06:34
Picon

[git pull] spi bug fixes for 2.6.37

Hi Linus.

Some spi bug fixes in this branch.

g.

The following changes since commit 3985c7ce85039adacdf882904ca096f091d39346:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
(2010-10-30 18:42:58 -0700)

are available in the git repository at:

  git://git.secretlab.ca/git/linux-2.6 next-spi

Feng Tang (1):
      spi: enable spi_board_info to be registered after spi_master

Linus Walleij (2):
      spi: fixed odd static string conventions in core code
      spi/pl022: fix erroneous platform data in U300

Michael Hennerich (2):
      spi/bfin_spi: handle error/status changes after data interrupts
      spi/bfin_spi: only request GPIO on first load

 arch/arm/mach-u300/spi.c  |    2 +-
 drivers/spi/spi.c         |   98 ++++++++++++++++++++++++---------------------
 drivers/spi/spi_bfin5xx.c |   22 ++++++++--
 include/linux/spi/spi.h   |    3 +
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Chinner | 1 Nov 2010 06:33

fs: inode freeing and hash lookup via RCU

Hi Al,

The following three patches implement the extra functionality you
wanted on top of the inode lock breakup. The first patch lifts the
i_lock up out of writeback_single_inode(), the second implements RCU
freeing of inodes via SLAB_DESTROY_BY_RCU, and the third converts
inode hash lookup operations to use RCU list walks. Comments are
welcome.

Cheers,

Dave.
Permalink | Reply | 11 comments |

Gmane