Re: mmotm 2008-09-08-18-32 uploaded

Re: mmotm 2008-09-08-18-32 uploaded

[KAMEZAWA Hiroyuki]

On Mon, 08 Sep 2008 18:35:16 -0700
akpm@linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> It contains the following patches against 2.6.27-rc5:
> 
Hmm, I'm not sure this is a trouble or not..

==
%quilt push -a
<snip>
|commit 5ca7e4a6b0929c7a0763f9b2481e063d9f047db0
|Author: Hans de Goede <j.w.r.degoede@hhs.nl>
|Date:   Wed Sep 3 17:12:20 2008 -0300
|
|    V4L/DVB (8831): gspca: Resolve webcam conflicts between some drivers.
|
|    -remove USB-id's from zc0301 for cams for which zc0301.c does not support
|      the sensor
|    -remove USB-id's from sn9c102 for cams where sn9c102 does not support the
|      bridge sensor combination
|    -no longer make inclusion of usb id's removed from zc0301 and sn9c102
|      conditional in gspca
|    -fix conditional inclusion of USB-id's in gspca to also work when the
|      conflicting drivers are build as a module
|    -add a number of USB-id's to gspca from various windows .inf files:
--------------------------
No file to patch.  Skipping patch.
patch: **** /tmp/po8iQmOc : No such file or directory
Patch ../patches/linux-next.patch does not apply (enforce with -f)

This stop is caused by following line in changelog.

    c45:608f from generic sonix sn9c103 inf file (+ ov7630 which we support)
    041e:4022 from creative webcam nx pro, same as already supported 041e:401e
    0ac8:0301 from generic zc0301 driver which supports many sensors
    10fd:804d from typhoon webshot driver (also FlyCAM-USB 300 plus)
and this line .
      converting those not to depend on consecutive minor numbers in commit
  ->  5a6411b1178baf534aa9138052864dfa89d3eada and later when dev0 was added

When I added a charactor in front of the number, linux-next.patch is applied.
Start from a number is bad ? (or my environment is bad ?)

Thanks,
-Kame

Re: mmotm 2008-09-08-18-32 uploaded

[Andrew Morton]

On Tue, 9 Sep 2008 17:37:53 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Mon, 08 Sep 2008 18:35:16 -0700
> akpm@linux-foundation.org wrote:
> 
> > The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > It contains the following patches against 2.6.27-rc5:
> > 
> Hmm, I'm not sure this is a trouble or not..
> 
> ==
> %quilt push -a
> <snip>
> |commit 5ca7e4a6b0929c7a0763f9b2481e063d9f047db0
> |Author: Hans de Goede <j.w.r.degoede@hhs.nl>
> |Date:   Wed Sep 3 17:12:20 2008 -0300
> |
> |    V4L/DVB (8831): gspca: Resolve webcam conflicts between some drivers.
> |
> |    -remove USB-id's from zc0301 for cams for which zc0301.c does not support
> |      the sensor
> |    -remove USB-id's from sn9c102 for cams where sn9c102 does not support the
> |      bridge sensor combination
> |    -no longer make inclusion of usb id's removed from zc0301 and sn9c102
> |      conditional in gspca
> |    -fix conditional inclusion of USB-id's in gspca to also work when the
> |      conflicting drivers are build as a module
> |    -add a number of USB-id's to gspca from various windows .inf files:
> --------------------------
> No file to patch.  Skipping patch.
> patch: **** /tmp/po8iQmOc : No such file or directory
> Patch ../patches/linux-next.patch does not apply (enforce with -f)
> 
> This stop is caused by following line in changelog.
> 
>     c45:608f from generic sonix sn9c103 inf file (+ ov7630 which we support)
>     041e:4022 from creative webcam nx pro, same as already supported 041e:401e
>     0ac8:0301 from generic zc0301 driver which supports many sensors
>     10fd:804d from typhoon webshot driver (also FlyCAM-USB 300 plus)
> and this line .
>       converting those not to depend on consecutive minor numbers in commit
>   ->  5a6411b1178baf534aa9138052864dfa89d3eada and later when dev0 was added
> 
> When I added a charactor in front of the number, linux-next.patch is applied.
> Start from a number is bad ? (or my environment is bad ?)

urgh, that's patch(1) being silly and interpreting that text as part of
a patch.  IIRC it's interpreting it as a context diff.

Adding `-u' to the `patch' command will shut it up.  That change should
be made to quilt (IMO).  

Re: mmotm 2008-09-08-18-32 uploaded

[KAMEZAWA Hiroyuki]

On Tue, 9 Sep 2008 01:43:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> > This stop is caused by following line in changelog.
> > 
> >     c45:608f from generic sonix sn9c103 inf file (+ ov7630 which we support)
> >     041e:4022 from creative webcam nx pro, same as already supported 041e:401e
> >     0ac8:0301 from generic zc0301 driver which supports many sensors
> >     10fd:804d from typhoon webshot driver (also FlyCAM-USB 300 plus)
> > and this line .
> >       converting those not to depend on consecutive minor numbers in commit
> >   ->  5a6411b1178baf534aa9138052864dfa89d3eada and later when dev0 was added
> > 
> > When I added a charactor in front of the number, linux-next.patch is applied.
> > Start from a number is bad ? (or my environment is bad ?)
> 
> urgh, that's patch(1) being silly and interpreting that text as part of
> a patch.  IIRC it's interpreting it as a context diff.
> 
> Adding `-u' to the `patch' command will shut it up.  That change should
> be made to quilt (IMO).  
> 
Oh, thank you.

-Kame

undefined reference to `v4l_printk_ioctl' [Was: mmotm 2008-09-08-18-32 uploaded]

[Jiri Slaby]

akpm@linux-foundation.org napsal(a):
> The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to

Hi,

CONFIG_VIDEO_DEV=m
CONFIG_COMPAT_VIDEO_DEV=y

causes:
drivers/built-in.o: In function `v4l_compat_ioctl32':
(.text+0x8db19): undefined reference to `v4l_printk_ioctl'

COMPAT_VIDEO_DEV should be tristate?

Re: mmotm 2008-09-08-18-32 uploaded

[Jiri Slaby]

akpm@linux-foundation.org napsal(a):
> The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to

Hi,

CONFIG_MII=n
CONFIG_R8169=y

causes:
drivers/built-in.o: In function `rtl8169_gset_xmii':
r8169.c:(.text+0x8b4ec): undefined reference to `mii_ethtool_gset'

R8169 should depend on MII?

Re: mmotm 2008-09-08-18-32 uploaded

[Randy Dunlap]

On Tue, 09 Sep 2008 11:32:10 +0200 Jiri Slaby wrote:

> akpm@linux-foundation.org napsal(a):
> > The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to
> 
> Hi,
> 
> CONFIG_MII=n
> CONFIG_R8169=y
> 
> causes:
> drivers/built-in.o: In function `rtl8169_gset_xmii':
> r8169.c:(.text+0x8b4ec): undefined reference to `mii_ethtool_gset'
> 
> R8169 should depend on MII?
> --

It should select MII.  That should change CONFIG_MII to =y.

---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

[PATCH 1/1] NET: fix r8169 linkage

[Jiri Slaby]

R8169 depends on MII code, thus select MII in Kconfig by R8169.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
---
 drivers/net/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 4c818d5..b0a5a17 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2034,6 +2034,7 @@ config R8169
 	tristate "Realtek 8169 gigabit ethernet support"
 	depends on PCI
 	select CRC32
+	select MII
 	---help---
 	  Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter.
 
-- 
1.6.0

Re: mmotm 2008-09-08-18-32 uploaded

[KAMEZAWA Hiroyuki]

On Mon, 08 Sep 2008 18:35:16 -0700
akpm@linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> It contains the following patches against 2.6.27-rc5:
> 

I'll dig if I have time. This is just a report.

I tries UnixBench4.1 on x86_64/2cpu/1socket machine. (memory cgroup is enabled)

Following is comparison with a mmtom based on rc4.
===
[rc4mm1]
Execl Throughput                           3004.4 lps   (29.6 secs, 3 samples)
C Compiler Throughput                      1017.9 lpm   (60.0 secs, 3 samples)
Shell Scripts (1 concurrent)               5726.3 lpm   (60.0 secs, 3 samples)
Shell Scripts (8 concurrent)               1124.3 lpm   (60.0 secs, 3 samples)
Shell Scripts (16 concurrent)               576.0 lpm   (60.0 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places         125446.5 lpm   (30.0 secs, 3 samples)

[rc5mm1]
Execl Throughput                           3006.5 lps   (29.8 secs, 3 samples)
C Compiler Throughput                      1006.7 lpm   (60.0 secs, 3 samples)
Shell Scripts (1 concurrent)               4863.7 lpm   (60.0 secs, 3 samples)
Shell Scripts (8 concurrent)                943.7 lpm   (60.0 secs, 3 samples)
Shell Scripts (16 concurrent)               482.7 lpm   (60.0 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places         124804.9 lpm   (30.0 secs, 3 samples)
==
15% down in shell script test. Any idea ? (scheduler ?)

Thanks,
-Kame

Re: mmotm 2008-09-08-18-32 uploaded

[Andrew Morton]

On Tue, 9 Sep 2008 19:25:44 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Mon, 08 Sep 2008 18:35:16 -0700
> akpm@linux-foundation.org wrote:
> 
> > The mm-of-the-moment snapshot 2008-09-08-18-32 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > It contains the following patches against 2.6.27-rc5:
> > 
> 
> I'll dig if I have time. This is just a report.
> 
> I tries UnixBench4.1 on x86_64/2cpu/1socket machine. (memory cgroup is enabled)
> 
> Following is comparison with a mmtom based on rc4.
> ===
> [rc4mm1]
> Execl Throughput                           3004.4 lps   (29.6 secs, 3 samples)
> C Compiler Throughput                      1017.9 lpm   (60.0 secs, 3 samples)
> Shell Scripts (1 concurrent)               5726.3 lpm   (60.0 secs, 3 samples)
> Shell Scripts (8 concurrent)               1124.3 lpm   (60.0 secs, 3 samples)
> Shell Scripts (16 concurrent)               576.0 lpm   (60.0 secs, 3 samples)
> Dc: sqrt(2) to 99 decimal places         125446.5 lpm   (30.0 secs, 3 samples)
> 
> [rc5mm1]
> Execl Throughput                           3006.5 lps   (29.8 secs, 3 samples)
> C Compiler Throughput                      1006.7 lpm   (60.0 secs, 3 samples)
> Shell Scripts (1 concurrent)               4863.7 lpm   (60.0 secs, 3 samples)
> Shell Scripts (8 concurrent)                943.7 lpm   (60.0 secs, 3 samples)
> Shell Scripts (16 concurrent)               482.7 lpm   (60.0 secs, 3 samples)
> Dc: sqrt(2) to 99 decimal places         124804.9 lpm   (30.0 secs, 3 samples)
> ==
> 15% down in shell script test. Any idea ? (scheduler ?)

Dunno.  There is a largel number of debugging patches at the tail of
the series so they should be the first thing to eliminate.

Re: mmotm 2008-09-08-18-32 uploaded

[KAMEZAWA Hiroyuki]

On Tue, 9 Sep 2008 10:37:41 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> > Following is comparison with a mmtom based on rc4.
> > ===
> > [rc4mm1]
> > Execl Throughput                           3004.4 lps   (29.6 secs, 3 samples)
> > C Compiler Throughput                      1017.9 lpm   (60.0 secs, 3 samples)
> > Shell Scripts (1 concurrent)               5726.3 lpm   (60.0 secs, 3 samples)
> > Shell Scripts (8 concurrent)               1124.3 lpm   (60.0 secs, 3 samples)
> > Shell Scripts (16 concurrent)               576.0 lpm   (60.0 secs, 3 samples)
> > Dc: sqrt(2) to 99 decimal places         125446.5 lpm   (30.0 secs, 3 samples)
> > 
> > [rc5mm1]
> > Execl Throughput                           3006.5 lps   (29.8 secs, 3 samples)
> > C Compiler Throughput                      1006.7 lpm   (60.0 secs, 3 samples)
> > Shell Scripts (1 concurrent)               4863.7 lpm   (60.0 secs, 3 samples)
> > Shell Scripts (8 concurrent)                943.7 lpm   (60.0 secs, 3 samples)
> > Shell Scripts (16 concurrent)               482.7 lpm   (60.0 secs, 3 samples)
> > Dc: sqrt(2) to 99 decimal places         124804.9 lpm   (30.0 secs, 3 samples)
> > ==
> > 15% down in shell script test. Any idea ? (scheduler ?)
> 
> Dunno.  There is a largel number of debugging patches at the tail of
> the series so they should be the first thing to eliminate.
> 
But I compare mmtom and mmtom, both includes debug series at the tail of series.
I'll revisit this later.

Thanks,
-Kame  

Re: mmotm 2008-09-08-18-32 uploaded

[Andrew Morton]

On Wed, 10 Sep 2008 10:01:42 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Tue, 9 Sep 2008 10:37:41 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > Following is comparison with a mmtom based on rc4.
> > > ===
> > > [rc4mm1]
> > > Execl Throughput                           3004.4 lps   (29.6 secs, 3 samples)
> > > C Compiler Throughput                      1017.9 lpm   (60.0 secs, 3 samples)
> > > Shell Scripts (1 concurrent)               5726.3 lpm   (60.0 secs, 3 samples)
> > > Shell Scripts (8 concurrent)               1124.3 lpm   (60.0 secs, 3 samples)
> > > Shell Scripts (16 concurrent)               576.0 lpm   (60.0 secs, 3 samples)
> > > Dc: sqrt(2) to 99 decimal places         125446.5 lpm   (30.0 secs, 3 samples)
> > > 
> > > [rc5mm1]
> > > Execl Throughput                           3006.5 lps   (29.8 secs, 3 samples)
> > > C Compiler Throughput                      1006.7 lpm   (60.0 secs, 3 samples)
> > > Shell Scripts (1 concurrent)               4863.7 lpm   (60.0 secs, 3 samples)
> > > Shell Scripts (8 concurrent)                943.7 lpm   (60.0 secs, 3 samples)
> > > Shell Scripts (16 concurrent)               482.7 lpm   (60.0 secs, 3 samples)
> > > Dc: sqrt(2) to 99 decimal places         124804.9 lpm   (30.0 secs, 3 samples)
> > > ==
> > > 15% down in shell script test. Any idea ? (scheduler ?)
> > 
> > Dunno.  There is a largel number of debugging patches at the tail of
> > the series so they should be the first thing to eliminate.
> > 
> But I compare mmtom and mmtom, both includes debug series at the tail of series.

oh, sorry, I didn't read closely enough.

Yes, someone broke something.

> I'll revisit this later.

I'd suggest testing linux-next as a first step.