headers
Jesper Nilsson | 1 Nov 2008 01:11
Picon
Favicon

[RFC git pull 2/2] Remove CRIS build links

Hi!

Again, I know this is a bit late in the game, thus the RFC, but I felt it
would be useful to have these changes in 2.6.28, and Sam Ravnborg
also encouraged me to get these in asap.

This second pull request contains two changes dependent on the first
pull request.

These two changes remove all uses of symbolic links in the CRIS port, making
it possible to build two CRIS architectures (with different O= parameters)
in parallell using the same source tree.

Please consider pulling the following changes since commit
556dcee7b829e5c350c3ffdbdb87a8b15aa3c5d3:
  Jesper Nilsson (1):
        [CRIS] Move header files from include to arch/cris/include.

are available in the git repository at:

      git://www.jni.nu/cris.git link_removal

Jesper Nilsson (2):
      [CRIS] Merge asm-offsets.c for both arches into one file.
      [CRIS] Remove links from CRIS build

 arch/cris/Makefile                            |   67 +++++----------
 arch/cris/arch-v10/kernel/asm-offsets.c       |   47 ----------
 arch/cris/arch-v10/vmlinux.lds.S              |  118 -------------------------
 arch/cris/arch-v32/boot/compressed/head.S     |   16 +++-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jay Vosburgh | 1 Nov 2008 01:16
Picon
Favicon

Re: [tbench regression fixes]: digging out smelly deadmen.

Stephen Hemminger <shemminger <at> vyatta.com> wrote:

>On Fri, 31 Oct 2008 16:51:44 -0700 (PDT)
>David Miller <davem <at> davemloft.net> wrote:
[...]
>> However, I do like Stephen's suggestion that maybe we can get rid of
>> this ->last_rx thing by encapsulating the logic completely in the
>> bonding driver.
>
>Since bonding driver doesn't actually see the rx packets, that isn't
>really possible.  But it would be possible to change last_rx from a variable
>to an function pointer, so that device's could apply other logic to derive
>the last value.  One example would be to keep it per cpu and then take the
>maximum.

	I suspect it could also be tucked away in skb_bond_should_drop,
which is called both by the standard input path and the VLAN accelerated
path to see if the packet should be tossed (e.g., it arrived on an
inactive bonding slave).

	Since last_rx is part of struct net_device, I don't think any
additional bonding internals knowledge would be needed.  It could be
arranged to only update last_rx for devices that are actually bonding
slaves.

	Just off the top of my head (haven't tested this), something
like this:

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c8bcb59..ed1e58f 100644
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alok Kataria | 1 Nov 2008 03:01
Favicon

Re: [PATCH 1/4] Check for serial key in dmi_name_in_vendors

> Since there is only one user, we could change that user, perhaps to take
> a bitmask or pointer to one of several canned lists as an argument, or
> we can introduce another entry point.

Hi hpa, 

I have added a new interface to check for a string in the product serial
information. And now i use this new interface to detect VMware.

This does not touch the dmi_name_in_vendors function, so the original
patch on this thread should be ignored.

Also please note that this new patch needs to be applied on top of the
hypervisor detection patch. 

Thanks,
Alok

--
DMI, check for the string in product serial key.

From: Alok N Kataria <akataria <at> vmware.com>

In some user configured cases, VMware may choose not to put VMware specific DMI
information, but the product serial key is always there and is VMware specific.
Add a interface to check the serial key, and use this new interface when
checking for VMware specific string in the DMI information.

Signed-off-by: Alok N Kataria <akataria <at> vmware.com>
---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Komuro | 1 Nov 2008 03:07
Favicon

[BUG REPORT!!!] [PATCH 19/49] pcmcia: remove remaining in-kernel pcmcia_get_configuration_info() users

Dear Dominik

Unfortunately, your path "[PATCH 19/49] pcmcia: remove remaining in-kernel
pcmcia_get_configuration_info() users"
broke the "serial_cs" and other drivers.

You replace "config->BasePort2" to "link->io.BasePort2" at serial_cs. 

But link->io.BasePort2, link->io.NumPorts2(etc) 
does not contain correct value (it is zero).

Please fix this problem (or reveart the patch).

Best Regards
Komuro

Here is your patch.
>--- a/drivers/serial/serial_cs.c
>+++ b/drivers/serial/serial_cs.c
> <at>  <at>  -488,23 +488,23  <at>  <at>  static int simple_config_check_notpicky(struct pcmcia_device *p_dev,
> static int simple_config(struct pcmcia_device *link)
> {
> 	struct serial_info *info = link->priv;
>-	config_info_t config;
>-	int i, try;
>+	int i = -ENODEV, try;
> 
> 	/* If the card is already configured, look up the port and irq */
>-	i = pcmcia_get_configuration_info(link, &config);
>-	if ((i == CS_SUCCESS) && (config.Attributes & CONF_VALID_CLIENT)) {
(Continue reading)

Permalink | Reply | 8 comments |
headers
Robert Richter | 1 Nov 2008 03:29
Picon
Favicon

Re: linux-2.6.28-rc2 regression : oprofile doesnt work anymore ?

Eric,

On 30.10.08 19:01:52, Eric Dumazet wrote:
> Hi
>
> I tried to start my favorite tool, and discovered it wont fly on my HP 
> BL460C G1
>
> It samples few events then, seems to stop (no more NMI), other than that, 
> machine
> still running correctly.

hmm, I can not reproduce this on my system. I am receiving samples and
the number is increasing. Andi, could you test this on some of your
systems?

-Robert

# opcontrol --dump; opreport 
CPU: AMD64 family10, speed 2100 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask)
count 100000
CPU_CLK_UNHALT...|
  samples|      %|
------------------
    70897 98.6970 vmlinux
      467  0.6501 libc-2.6.1.so
      219  0.3049 bash
      141  0.1963 ld-2.6.1.so
       43  0.0599 oprofiled
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wu Fengguang | 1 Nov 2008 03:33
Picon

Re: readahead in the 2.6.25+ kernel

Hi John,

On Fri, Oct 31, 2008 at 09:00:30PM -0400, John Galloway wrote:
> 
> Hi,
> 
>   I'm looking into read ahead issues wrt Ingres, particularly wrt mmap.
> I gather (but am not sure) your readahead patches have been incorporated
> into the 2.6 kernel around 2.6.15, with some simplfications it seems??
> Are you still maintaining a distinct patch set?

The ondemand readahead patch series have been merged into linux 2.6.23/24.
So I no longer maintain out-of-tree readahead patches.

>   And can you help me out about how linux readahead will effect mmap() as
> opposed to read()?  i.e. is it enabled for mmap() as well?

No, mmap readahead is always a dumb and simple 'read-around' one, and
it seems there is no general interest on improving it.

Currently you have two options to affect mmap readahead performance:
- tune readahead size with command `blockdev --setra'
- tell kernel to use the ondemand readahead routines with
  madvise(MADV_SEQUENTIAL)

Note that MADV_SEQUENTIAL is safe to use at least for the current
readahead implementation, it won't blindly do aggressive readahead on
seeing MADV_SEQUENTIAL. The flag only switches the readahead routine
from the dumb read-around one to the somehow smarter readahead logic,
which _detects_ sequential patterns for us.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Beregalov | 1 Nov 2008 03:43
Picon

[PATCH] Staging: remove double #include


Signed-off-by: Alexander Beregalov <a.beregalov <at> gmail.com>
---

 drivers/staging/echo/echo.c     |    1 -
 drivers/staging/me4000/me4000.c |    1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/echo/echo.c b/drivers/staging/echo/echo.c
index b8f2c5e..fd4007e 100644
--- a/drivers/staging/echo/echo.c
+++ b/drivers/staging/echo/echo.c
 <at>  <at>  -106,7 +106,6  <at>  <at> 

 #include <linux/kernel.h>	/* We're doing kernel work */
 #include <linux/module.h>
-#include <linux/kernel.h>
 #include <linux/slab.h>

 #include "bit_operations.h"
diff --git a/drivers/staging/me4000/me4000.c b/drivers/staging/me4000/me4000.c
index 0b33773..cddac25 100644
--- a/drivers/staging/me4000/me4000.c
+++ b/drivers/staging/me4000/me4000.c
 <at>  <at>  -39,7 +39,6  <at>  <at> 
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/system.h>
-#include <asm/uaccess.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Clements | 1 Nov 2008 03:50

2.6.28-rc2-git6 fails compile -- cpu/common.c

Fyi
2.6.28-rc2-git fails compile, uniprocessor x86. (Missed git4 and git5.)

  CC      arch/x86/kernel/cpu/common.o
arch/x86/kernel/cpu/common.c: In function 'cpu_init':
arch/x86/kernel/cpu/common.c:1141: error: 'boot_cpu_id' undeclared (first use in this function)
arch/x86/kernel/cpu/common.c:1141: error: (Each undeclared identifier is reported only once
arch/x86/kernel/cpu/common.c:1141: error: for each function it appears in.)
make[2]: *** [arch/x86/kernel/cpu/common.o] Error 1
make[1]: *** [arch/x86/kernel/cpu] Error 2
make: *** [arch/x86/kernel] Error 2

--

-- 
Pete Clements
Permalink | Reply | 2 comments |
headers
Ming Lei | 1 Nov 2008 05:25
Picon

Re: [beagleboard] Diff between Linux-2.6.27-omap1-dirty and Linux-2.6.27-omap1 ?

I also have this problem, even git-tree is not dirty.
Why?

Thanks!
------------------------------------------------------------
Texas Instruments X-Loader 1.41
Starting OS Bootloader...

U-Boot 1.3.3 (Jul 10 2008 - 16:33:09)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
DRAM:  128 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Audio Tone on Speakers  ... complete
Hit any key to stop autoboot:  0
OMAP3 beagleboard.org #
OMAP3 beagleboard.org #
OMAP3 beagleboard.org # printenv
bootargs=console=ttyS2,115200n8 ramdisk_size=8192 root=/dev/ram0 rw
rootfstype=ext2 initrd=0x81600000f
bootcmd=mmcinit;fatload mmc 0 0x80300000 uImage;fatload mmc 0
0x81600000 rd-ext2.bin;bootm 0x80300000
stdin=serial
stdout=serial
stderr=serial
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Chapman | 1 Nov 2008 05:48
Picon
Picon
Favicon

ALPS input driver problem with DualPoint on Dell E6400/E6500

I have a Dell Latitude E6400 laptop with an ALPS touchpad/touchstick
combination, aka DualPoint.  Individually, the touchpad and touchstick
work fine.  However, if I accidentally touch both together, or use the
touchpad buttons while using the touchstick (or vice versa), things go
astray.  The pointer jumps around, stray mouse buttons are pressed, and
the driver typically loses sync:

[13333.661085] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0
lost sync at byte 5
[13333.662353] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0
lost sync at byte 1
[13333.669493] psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 -
driver resynched.

To cut a long story short, it seems that in this case the ALPS device
sends a 9-byte packet format, with both a relative update and an
absolute update combined (why oh why...).  Has anyone else seen
something like this?

When I use just the touchstick and its buttons, the packets are normal
PS/2 relative mode packets, e.g.:

  08 01 00    dx=1 dy=0
  09 01 00    dx=1 dy=0   left T/S button down
  08 00 01    dx=0 dy=1   left T/S button up

When I use just the touchpad and its buttons, the packets look like
this, which also works fine with the current ALPS code:

  cf 27 1a 38 24 46   x=423 y=420 z=70 fin=1
(Continue reading)

Permalink | Reply | 2 comments |

Gmane