2010-12-27 06:05:09

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: Tree for December 27

Hi all,

[The mirroring on kernel.org is running slowly]

Changes since 20101221:

Linus' tree lost its build failure.

The omap tree gained a conflict against the arm tree.

The ux500-core tree gained a build failure for which I reverted a commit.

The sh tree gained a conflict against the sh-current tree.

The pci tree lost its conflicts.

The kvm tree lost its conflict.

The net tree gained a conflict against Linus' tree.

The wireless tree lost its conflicts.

The sound tree gained a build failure, so I used the version that would
have been in next-20101223.

The sound-asoc tree also had a build failure, so I used the version from
next-20101221.

The trivial tree lost its conflicts.

The workqueues tree gained conflicts against the tip and v4l-dvb trees.

The tty tree still has its build failure so I reverted a commit.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 183 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.

--
Cheers,
Stephen Rothwell [email protected]

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/rc-fixes
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging fbdev-current/fbdev-fixes-for-linus
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging linux-spec/for-next
Merging msm/for-next
Merging omap/for-next
CONFLICT (content): Merge conflict in arch/arm/plat-omap/Kconfig
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/timer.c
Merging ux500-core/ux500-core
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
CONFLICT (content): Merge conflict in arch/sh/kernel/cpu/sh2a/clock-sh7201.c
Merging rmobile/rmobile-latest
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/Kconfig
Applying: rmobile: merge fixup for clkdev changes
Merging sparc/master
Merging tile/master
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
CONFLICT (content): Merge conflict in fs/cifs/dir.c
CONFLICT (content): Merge conflict in fs/fuse/inode.c
CONFLICT (content): Merge conflict in fs/hfsplus/hfsplus_fs.h
CONFLICT (content): Merge conflict in fs/hfsplus/unicode.c
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in net/9p/protocol.c
CONFLICT (content): Merge conflict in net/ipv4/fib_frontend.c
Merging wireless/master
Merging bluetooth/master
CONFLICT (content): Merge conflict in net/bluetooth/Makefile
Merging mtd/master
Merging crypto/master
Merging sound/for-next
CONFLICT (rename/modify): Merge conflict in sound/soc/samsung/smdk_wm8580.c
CONFLICT (rename/modify): Merge conflict in sound/soc/samsung/smdk_wm9713.c
CONFLICT (add/add): Merge conflict in arch/arm/plat-samsung/dev-asocdma.c
$ git reset --hard HEAD^
Merging refs/next/20101223/sound
CONFLICT (rename/modify): Merge conflict in sound/soc/samsung/smdk_wm8580.c
CONFLICT (rename/modify): Merge conflict in sound/soc/samsung/smdk_wm9713.c
CONFLICT (add/add): Merge conflict in arch/arm/plat-samsung/dev-asocdma.c
[master 399efb0] Merge commit 'refs/next/20101223/sound'
Merging sound-asoc/for-next
$ git reset --hard HEAD^
Merging refs/next/20101221/sound-asoc
Merging cpufreq/next
Merging quilt/rr
Merging input/next
CONFLICT (content): Merge conflict in drivers/input/keyboard/Kconfig
CONFLICT (content): Merge conflict in include/linux/input.h
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/mfd/Makefile
CONFLICT (content): Merge conflict in drivers/mfd/wm8994-core.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
CONFLICT (content): Merge conflict in drivers/regulator/core.c
CONFLICT (content): Merge conflict in drivers/regulator/mc13783-regulator.c
Merging security-testing/next
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging suspend/linux-next
Merging fsnotify/for-next
Merging irda/for-next
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in drivers/Makefile
CONFLICT (content): Merge conflict in include/linux/Kbuild
CONFLICT (content): Merge conflict in lib/Kconfig
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging tip/auto-latest
Merging rcu/rcu/next
Merging oprofile/for-next
Merging xen/upstream/xen
Merging swiotlb-xen/master
CONFLICT (content): Merge conflict in drivers/xen/Kconfig
CONFLICT (content): Merge conflict in drivers/xen/Makefile
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in drivers/media/video/bt8xx/bttv-input.c
CONFLICT (content): Merge conflict in drivers/rtc/rtc-dev.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging driver-core/driver-core-next
Merging tty/tty-next
[master ed994a8] Revert "drivers: serial: apbuart: Handle OF failures gracefully"
Merging usb/usb-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/Kconfig
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clock3xxx_data.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clock44xx_data.c
CONFLICT (content): Merge conflict in arch/sh/Kconfig
Merging staging/staging-next
Merging slabh/slabh
Merging bkl-trivial/trivial
Merging bkl-llseek/llseek
Merging bkl-vfs/vfs
Merging bkl-config/config
CONFLICT (content): Merge conflict in arch/powerpc/kernel/setup_64.c
CONFLICT (content): Merge conflict in include/linux/hardirq.h
CONFLICT (content): Merge conflict in include/linux/smp_lock.h
Merging irqflags/master
Merging cleancache/linux-next
CONFLICT (content): Merge conflict in fs/ocfs2/super.c
CONFLICT (content): Merge conflict in fs/super.c
CONFLICT (content): Merge conflict in include/linux/fs.h
CONFLICT (content): Merge conflict in mm/Kconfig
Merging scsi-post-merge/merge-base:master
$ git checkout scsi-post-merge/master
Applying: [SCSI] target: Add LIO target core v4.0.0-rc6
Applying: [SCSI] sd: implement sd_check_events()
[master 7fdf0d2] Revert "input/tc3589x: add tc3589x keypad support"


Attachments:
(No filename) (10.44 kB)
(No filename) (490.00 B)
Download all attachments

2010-12-27 08:05:07

by Sedat Dilek

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 7:04 AM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> [The mirroring on kernel.org is running slowly]
>
> Changes since 20101221:
>

Can you try to upload/push via IPADDR?

$ host git.kernel.org
git.kernel.org is an alias for git.geo.kernel.org.
git.geo.kernel.org is an alias for git.eu.kernel.org.
git.eu.kernel.org has address 199.6.1.166
git.eu.kernel.org has address 130.239.17.7

Being in EU, I get nearly maximum of my DSL-6000 download-rate:

$ git clone git://130.239.17.7/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
Cloning into linux-npiggin...
remote: Counting objects: 1812908, done.
remote: Compressing objects: 100% (279491/279491), done.
Receiving objects: 13% (252336/1812908), 111.50 MiB | 689 KiB/s

> The sound tree gained a build failure, so I used the version that would
> have been in next-20101223.
>

I thought there was no "next-20101223" :-).

Can you please upload the patch-diff to
<http://www.kernel.org/pub/linux/kernel/v2.6/next/>?
Thanks in advance.

- Sedat -

2010-12-27 09:12:06

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

Hi,

On Mon, 27 Dec 2010 09:04:06 +0100 Sedat Dilek <[email protected]> wrote:
>
> Can you try to upload/push via IPADDR?

I can only upload to master.kernel.org, the rest is done by the mirroring
software. I have no access to any of the other kernel.org machines.

> > The sound tree gained a build failure, so I used the version that would
> > have been in next-20101223.
>
> I thought there was no "next-20101223" :-).

That is why I said "would have been in" :-)

> Can you please upload the patch-diff to
> <http://www.kernel.org/pub/linux/kernel/v2.6/next/>?

If you mean for next-20101223, then there wasn't one. I ran out of time
and just threw away what I had done.

If you mean generally, then (see above) it depends on the mirroring
software.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (869.00 B)
(No filename) (490.00 B)
Download all attachments

2010-12-27 09:55:35

by Sedat Dilek

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 10:11 AM, Stephen Rothwell <[email protected]> wrote:
> Hi,
>
> On Mon, 27 Dec 2010 09:04:06 +0100 Sedat Dilek <[email protected]> wrote:
>>
>> Can you try to upload/push via IPADDR?
>
> I can only upload to master.kernel.org, the rest is done by the mirroring
> software.  I have no access to any of the other kernel.org machines.
>

I was wondering about still "slow mirrors" as also checking out before
Xmas was very slow.
Now, seeing from an end-users point, the checking-out is just fine.
I tried to clone
"$GIT_MIRROR/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git" where
GIT_MIRROR was:

1. git://130.239.17.7
2. git://199.6.1.166
3. git//git.kernel.org
4. git//git.eu.kernel.org

All checkouts had around 680-690KiB/s.

[...]

>> Can you please upload the patch-diff to
>> <http://www.kernel.org/pub/linux/kernel/v2.6/next/>?
>
> If you mean for next-20101223, then there wasn't one.  I ran out of time
> and just threw away what I had done.
>
> If you mean generally, then (see above) it depends on the mirroring
> software.
>

Dunno what you mean with "mirroring software", but I am primarily
interested in the patch-v2.6.37-rc7-next-20101227 than in an updated
linux-next GIT repo.
IMHO, it should be possible to generate this patch from your local GIT
repo and upload the diff-patch to whereever is fast and accessible by
you.
My kernel-build-system has as base a vanilla upstream (here:
2.6.37-rc7) against which I apply an individual patch-series incl. the
linux-next diff-patch.
Hope this helps a bit to understand what I was talking about.

- Sedat -

2010-12-27 11:39:02

by Mark Brown

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 05:04:51PM +1100, Stephen Rothwell wrote:

> The sound-asoc tree also had a build failure, so I used the version from
> next-20101221.

What is the problem you are seeing in the sound-asoc tree? I saw a mail
about the sound tree but didn't see any failures reported for ASoC.

2010-12-27 12:09:20

by Sedat Dilek

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 10:55 AM, Sedat Dilek
<[email protected]> wrote:
> On Mon, Dec 27, 2010 at 10:11 AM, Stephen Rothwell <[email protected]> wrote:
>> Hi,
>>
>> On Mon, 27 Dec 2010 09:04:06 +0100 Sedat Dilek <[email protected]> wrote:
>>>
>>> Can you try to upload/push via IPADDR?
>>
>> I can only upload to master.kernel.org, the rest is done by the mirroring
>> software.  I have no access to any of the other kernel.org machines.
>>
>
> I was wondering about still "slow mirrors" as also checking out before
> Xmas was very slow.
> Now, seeing from an end-users point, the checking-out is just fine.
> I tried to clone
> "$GIT_MIRROR/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git" where
> GIT_MIRROR was:
>
> 1. git://130.239.17.7
> 2. git://199.6.1.166
> 3. git//git.kernel.org
> 4. git//git.eu.kernel.org
>
> All checkouts had around 680-690KiB/s.
>

DAMN!
The above was with cloning the vfs-tree from Nick Piggin, with
linux-next GIT it is a difference from where you clone (from my
GeoIP-location):

$ git clone git://130.239.17.7/pub/scm/linux/kernel/git/next/linux-next.git
Cloning into linux-next...
remote: Counting objects: 3164616, done.
remote: Compressing objects: 100% (416281/416281), done.
remote: Total 3164616 (delta 2756821), reused 3128824 (delta 2721031)
Receiving objects: 100% (3164616/3164616), 535.89 MiB | 685 KiB/s, done.
Resolving deltas: 100% (2756821/2756821), done.

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Cloning into linux-next...
remote: Counting objects: 3164616, done.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Anyway, it would be great if someone of the resposibles for the
kernel-mirrors would take care of these problems.

- Sedat -

2010-12-27 14:36:52

by Piotr Hosowicz

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On 27.12.2010 07:04, Stephen Rothwell wrote:

Hello,

I noticed that after first reboot with this kernel that my MP3
collection in mocp layed on Ext4 fs opens painfully slow. It is not my
mistake, because I always do it the same way, new kernel, then music on.
The problem is not present in rc7-git4. I could measure it in some way
(timing ls -la in tht dir?) if somebody needs it.

Regards,

Piotr Hosowicz

--
Demokracja to kult szakali wyznawany przez os?y (Henry Louis Mencken)
NP: Peter Green Splinter Group - Big Change Is Gonna Come
NB: 2.6.37-rc7-next-20101227

2010-12-27 14:48:30

by Sedat Dilek

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

2010/12/27 Piotr Hosowicz <[email protected]>:
> On 27.12.2010 07:04, Stephen Rothwell wrote:
>
> Hello,
>
> I noticed that after first reboot with this kernel that my MP3 collection in
> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because I
> always do it the same way, new kernel, then music on. The problem is not
> present in rc7-git4. I could measure it in some way (timing ls -la in tht
> dir?) if somebody needs it.
>
> Regards,
>
> Piotr Hosowicz
>

You tried mblk_io_submit mount-option for that partition?

- Sedat -

2010-12-27 14:58:03

by Piotr Hosowicz

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On 27.12.2010 15:48, Sedat Dilek wrote:
> 2010/12/27 Piotr Hosowicz<[email protected]>:
>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>
>> Hello,
>>
>> I noticed that after first reboot with this kernel that my MP3 collection in
>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because I
>> always do it the same way, new kernel, then music on. The problem is not
>> present in rc7-git4. I could measure it in some way (timing ls -la in tht
>> dir?) if somebody needs it.
>>
>> Regards,
>>
>> Piotr Hosowicz
>>
>
> You tried mblk_io_submit mount-option for that partition?

No, I do not use it, I do not even know what it is. My options are:

/dev/sda2 on / type ext4 (rw,errors=remount-ro)

Regards,

Piotr Hosowicz

--
Jest jedna korzy?? z posiadania TV - jak dobrze
rozregulujesz odbiornik, trafisz na promieniowanie
mikrofalowe z pocz?tk?w Wszech?wiata.
NP: Peter Green Splinter Group - Burglar
NB: 2.6.37-rc7-next-20101227

2010-12-27 15:08:14

by Sedat Dilek

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

2010/12/27 Piotr Hosowicz <[email protected]>:
> On 27.12.2010 15:48, Sedat Dilek wrote:
>>
>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>
>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>
>>> Hello,
>>>
>>> I noticed that after first reboot with this kernel that my MP3 collection
>>> in
>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because
>>> I
>>> always do it the same way, new kernel, then music on. The problem is not
>>> present in rc7-git4. I could measure it in some way (timing ls -la in tht
>>> dir?) if somebody needs it.
>>>
>>> Regards,
>>>
>>> Piotr Hosowicz
>>>
>>
>> You tried mblk_io_submit mount-option for that partition?
>
> No, I do not use it, I do not even know what it is. My options are:
>
> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>

Have a closer look at "ext4: Turn off multiple page-io submission by default"

- Sedat -

[1] http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commit;h=1449032be17abb69116dbc393f67ceb8bd034f92

2010-12-27 15:13:59

by Piotr Hosowicz

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On 27.12.2010 16:08, Sedat Dilek wrote:
> 2010/12/27 Piotr Hosowicz<[email protected]>:
>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>
>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>
>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>
>>>> Hello,
>>>>
>>>> I noticed that after first reboot with this kernel that my MP3 collection
>>>> in
>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because
>>>> I
>>>> always do it the same way, new kernel, then music on. The problem is not
>>>> present in rc7-git4. I could measure it in some way (timing ls -la in tht
>>>> dir?) if somebody needs it.
>>>>
>>>> Regards,
>>>>
>>>> Piotr Hosowicz
>>>>
>>>
>>> You tried mblk_io_submit mount-option for that partition?
>>
>> No, I do not use it, I do not even know what it is. My options are:
>>
>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>
>
> Have a closer look at "ext4: Turn off multiple page-io submission by default"

I tried to Google for mblk_io_submit but I didn't find anything helpful.
Could you tell me how should I add this option in fstab and what will be
its effect?

Regards and thanks in advance,

Piotr Hosowicz

--
R??nica mi?dzy PiS, a PO jest taka, ?e PO nie zro-
bi?a liberalizacji, a PiS nie zrobi? lustracji.
NP: Peter Green Splinter Group - I Can't Help Myself
NB: 2.6.37-rc7-next-20101227

2010-12-27 15:20:34

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

Hi Mark,

On Mon, 27 Dec 2010 11:38:58 +0000 Mark Brown <[email protected]> wrote:
>
> On Mon, Dec 27, 2010 at 05:04:51PM +1100, Stephen Rothwell wrote:
>
> > The sound-asoc tree also had a build failure, so I used the version from
> > next-20101221.
>
> What is the problem you are seeing in the sound-asoc tree? I saw a mail
> about the sound tree but didn't see any failures reported for ASoC.

I got this error after merging the sound tree:

ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8962.ko] undefined!

after that, I merged the old version of the sound tree. I then merged
the sound-asoc tree and go the same error. I presumed that you had fixed
the other error:

ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8903.ko] undefined!

in the sound-asoc tree and then that version of the sound-asoc tree had
been merged into the sound tree.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (0.99 kB)
(No filename) (490.00 B)
Download all attachments

2010-12-27 15:38:33

by Mark Brown

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On Tue, Dec 28, 2010 at 02:20:27AM +1100, Stephen Rothwell wrote:

> I got this error after merging the sound tree:

> ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8962.ko] undefined!

> after that, I merged the old version of the sound tree. I then merged
> the sound-asoc tree and go the same error. I presumed that you had fixed
> the other error:

> ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8903.ko] undefined!

> in the sound-asoc tree and then that version of the sound-asoc tree had
> been merged into the sound tree.

To my knowledge I'd fixed everything. However, it looks like there's a
typo in the wm8962 ifdef to work around the x86 failure which was
causing the problem; since you hadn't mentioned that you'd encountered
any issue after I'd done the previous fix I'd no idea that this had
happened and it had appeared that the problem with Takashi's tree was
simply that he'd not merged up the fix.

Fixed now, anyway. Please do report if you see any more issues.

2010-12-27 15:45:43

by Piotr Hosowicz

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On 27.12.2010 16:13, Piotr Hosowicz wrote:
> On 27.12.2010 16:08, Sedat Dilek wrote:
>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>
>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>
>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>> collection
>>>>> in
>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>> because
>>>>> I
>>>>> always do it the same way, new kernel, then music on. The problem
>>>>> is not
>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>> in tht
>>>>> dir?) if somebody needs it.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Piotr Hosowicz
>>>>>
>>>>
>>>> You tried mblk_io_submit mount-option for that partition?
>>>
>>> No, I do not use it, I do not even know what it is. My options are:
>>>
>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>
>>
>> Have a closer look at "ext4: Turn off multiple page-io submission by
>> default"
>
> I tried to Google for mblk_io_submit but I didn't find anything helpful.
> Could you tell me how should I add this option in fstab and what will be
> its effect?

As far as I understand that option regards writing, not reading. The
symptoms I described occured while reading only.

Regards,

Piotr Hosowicz

--
TV: "W tej chwili, ?e si? tak wyra??, zaliczonych mamy 17 zawodniczek."
NP: Peter Green Splinter Group - Say That You Want To
NB: 2.6.37-rc7-next-20101227

2010-12-27 16:16:43

by Sedat Dilek

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

2010/12/27 Piotr Hosowicz <[email protected]>:
> On 27.12.2010 16:13, Piotr Hosowicz wrote:
>>
>> On 27.12.2010 16:08, Sedat Dilek wrote:
>>>
>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>
>>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>>
>>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>>
>>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>>> collection
>>>>>> in
>>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>>> because
>>>>>> I
>>>>>> always do it the same way, new kernel, then music on. The problem
>>>>>> is not
>>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>>> in tht
>>>>>> dir?) if somebody needs it.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Piotr Hosowicz
>>>>>>
>>>>>
>>>>> You tried mblk_io_submit mount-option for that partition?
>>>>
>>>> No, I do not use it, I do not even know what it is. My options are:
>>>>
>>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>>
>>>
>>> Have a closer look at "ext4: Turn off multiple page-io submission by
>>> default"
>>
>> I tried to Google for mblk_io_submit but I didn't find anything helpful.
>> Could you tell me how should I add this option in fstab and what will be
>> its effect?
>
> As far as I understand that option regards writing, not reading. The
> symptoms I described occured while reading only.
>

That's the only performance issue I am aware of in ext4 in recent time.
Why don't you try it and present some numbers in transfer ratio (write, read)?

- Sedat -

2010-12-27 19:23:51

by Randy Dunlap

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27 (drivers/target/)

On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:

> Hi all,
>
> [The mirroring on kernel.org is running slowly]

yep :(

> Changes since 20101221:


When CONFIG_SCSI is not enabled:

ERROR: "scsi_device_type" [drivers/target/target_core_mod.ko] undefined!

from target_core_transport.c::1586:

printk(" Type: %s ", scsi_device_type(device_type));


Also please update MAINTAINERS for drivers/target/.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/

2010-12-27 19:56:18

by Randy Dunlap

[permalink] [raw]
Subject: [PATCH -next] ocfs2: fix build for OCFS2_FS_STATS not enabled

From: Randy Dunlap <[email protected]>

When CONFIG_OCFS2_FS_STATS is not enabled:

fs/ocfs2/cluster/tcp.c:1254: error: implicit declaration of function 'o2net_update_recv_stats'

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: [email protected]
---
fs/ocfs2/cluster/tcp.c | 2 ++
1 file changed, 2 insertions(+)

--- linux-next-20101227.orig/fs/ocfs2/cluster/tcp.c
+++ linux-next-20101227/fs/ocfs2/cluster/tcp.c
@@ -257,6 +257,8 @@ static void o2net_update_recv_stats(stru

# define o2net_update_send_stats(a, b)

+# define o2net_update_recv_stats(sc)
+
#endif /* CONFIG_OCFS2_FS_STATS */

static inline int o2net_reconnect_delay(void)

2010-12-27 19:58:47

by Randy Dunlap

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27 (drivers/target)

On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:

> Hi all,
>
> [The mirroring on kernel.org is running slowly]
>
> Changes since 20101221:
>
> Linus' tree lost its build failure.


Hi Nick,

Please test building target code when CONFIG_BLOCK is not enabled.

When CONFIG_BLOCK is not enabled, drivers/target/ gets a boat load of build errors.

Should TCM_IBLOCK depend on BLOCK? That fixes lots of the build errors,
but not all of them.


The header file include/target/target_core_base.h uses struct queue_limits,
so it should #include <linux/blkdev.h>.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/

2010-12-27 20:54:17

by Joel Becker

[permalink] [raw]
Subject: Re: [PATCH -next] ocfs2: fix build for OCFS2_FS_STATS not enabled

On Mon, Dec 27, 2010 at 11:55:08AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> When CONFIG_OCFS2_FS_STATS is not enabled:
>
> fs/ocfs2/cluster/tcp.c:1254: error: implicit declaration of function 'o2net_update_recv_stats'
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Mark Fasheh <[email protected]>
> Cc: Joel Becker <[email protected]>
> Cc: [email protected]

Acked-by: Joel Becker <[email protected]>

Do you want to push it or would you like me to?

Joel

--

"But all my words come back to me
In shades of mediocrity.
Like emptiness in harmony
I need someone to comfort me."

Joel Becker
Senior Development Manager
Oracle
E-mail: [email protected]
Phone: (650) 506-8127

2010-12-27 21:43:50

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH -next] ocfs2: fix build for OCFS2_FS_STATS not enabled

On 12/27/10 12:52, Joel Becker wrote:
> On Mon, Dec 27, 2010 at 11:55:08AM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap <[email protected]>
>>
>> When CONFIG_OCFS2_FS_STATS is not enabled:
>>
>> fs/ocfs2/cluster/tcp.c:1254: error: implicit declaration of function 'o2net_update_recv_stats'
>>
>> Signed-off-by: Randy Dunlap <[email protected]>
>> Cc: Mark Fasheh <[email protected]>
>> Cc: Joel Becker <[email protected]>
>> Cc: [email protected]
>
> Acked-by: Joel Becker <[email protected]>
>
> Do you want to push it or would you like me to?

You, please.

--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/

2010-12-27 22:53:38

by Nicholas A. Bellinger

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27 (drivers/target/)

On Mon, 2010-12-27 at 11:21 -0800, Randy Dunlap wrote:
> On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > [The mirroring on kernel.org is running slowly]
>
> yep :(
>
> > Changes since 20101221:
>
>
> When CONFIG_SCSI is not enabled:
>
> ERROR: "scsi_device_type" [drivers/target/target_core_mod.ko] undefined!
>
> from target_core_transport.c::1586:
>
> printk(" Type: %s ", scsi_device_type(device_type));
>

Hi Randy and Stephen,

As there is really no a reason for building CONFIG_TARGET_CORE w/o
CONFIG_SCSI && CONFIG_BLOCK, the following patch has been added to the
new linux-next target tree here:

target: Add SCSI and BLOCK depends for TARGET_CORE
http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=15c8da9639029ac337dd2f0bb67010de62d4b724

>
> Also please update MAINTAINERS for drivers/target/.
>

Also added here, thanks for the reminder:

target: Add drivers/target/ entry to MAINTAINERS
http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=85356c6c328b3c4add3d240e387087a76a469028

Best Regards,

--nab

2010-12-27 22:55:36

by Nicholas A. Bellinger

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27 (drivers/target)

On Mon, 2010-12-27 at 11:57 -0800, Randy Dunlap wrote:
> On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > [The mirroring on kernel.org is running slowly]
> >
> > Changes since 20101221:
> >
> > Linus' tree lost its build failure.
>
>
> Hi Nick,
>
> Please test building target code when CONFIG_BLOCK is not enabled.
>
> When CONFIG_BLOCK is not enabled, drivers/target/ gets a boat load of build errors.
>
> Should TCM_IBLOCK depend on BLOCK? That fixes lots of the build errors,
> but not all of them.
>
>
> The header file include/target/target_core_base.h uses struct queue_limits,
> so it should #include <linux/blkdev.h>.
>
>

Added the missing include here:

target: Add linux/blkdev.h include in target_core_base.h
http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=e8bd07d3a525e71b424d308fc5084b89a6456bb2

Thanks Randy!

--nab

2010-12-28 14:27:29

by Piotr Hosowicz

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On 27.12.2010 17:16, Sedat Dilek wrote:
> 2010/12/27 Piotr Hosowicz<[email protected]>:
>> On 27.12.2010 16:13, Piotr Hosowicz wrote:
>>>
>>> On 27.12.2010 16:08, Sedat Dilek wrote:
>>>>
>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>
>>>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>>>
>>>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>>>
>>>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>>>> collection
>>>>>>> in
>>>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>>>> because
>>>>>>> I
>>>>>>> always do it the same way, new kernel, then music on. The problem
>>>>>>> is not
>>>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>>>> in tht
>>>>>>> dir?) if somebody needs it.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Piotr Hosowicz
>>>>>>>
>>>>>>
>>>>>> You tried mblk_io_submit mount-option for that partition?
>>>>>
>>>>> No, I do not use it, I do not even know what it is. My options are:
>>>>>
>>>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>>>
>>>>
>>>> Have a closer look at "ext4: Turn off multiple page-io submission by
>>>> default"
>>>
>>> I tried to Google for mblk_io_submit but I didn't find anything helpful.
>>> Could you tell me how should I add this option in fstab and what will be
>>> its effect?
>>
>> As far as I understand that option regards writing, not reading. The
>> symptoms I described occured while reading only.
>>
>
> That's the only performance issue I am aware of in ext4 in recent time.
> Why don't you try it and present some numbers in transfer ratio (write, read)?

Ok, I'll try to measure it in shell. Now I am building newest non-next
kernel and the trial script is:

#!/bin/bash

uname -a
mount
cd /data/music
time ls -d *
cd -

This is basically what mocp does when it enters my music directory,
apart from displaying the results in ncurses based UI. Then I'll reboot
with next kernel and run it again. Will it do?

Regards,

Piotr Hosowicz

--
Kto? zapuka? do drzwi.
-Bormann - pomy?la? Stirlitz
-Tak, to ja - pomy?la? Bormann
NP: Peter Green Splinter Group - Madison Blues
NB: 2.6.37-rc7-20101227-pztidm+

2010-12-28 15:09:34

by Piotr Hosowicz

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27

On 28.12.2010 15:27, Piotr Hosowicz wrote:
> On 27.12.2010 17:16, Sedat Dilek wrote:
>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>> On 27.12.2010 16:13, Piotr Hosowicz wrote:
>>>>
>>>> On 27.12.2010 16:08, Sedat Dilek wrote:
>>>>>
>>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>>
>>>>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>>>>
>>>>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>>>>
>>>>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>>>>> collection
>>>>>>>> in
>>>>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>>>>> because
>>>>>>>> I
>>>>>>>> always do it the same way, new kernel, then music on. The problem
>>>>>>>> is not
>>>>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>>>>> in tht
>>>>>>>> dir?) if somebody needs it.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Piotr Hosowicz
>>>>>>>>
>>>>>>>
>>>>>>> You tried mblk_io_submit mount-option for that partition?
>>>>>>
>>>>>> No, I do not use it, I do not even know what it is. My options are:
>>>>>>
>>>>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>>>>
>>>>>
>>>>> Have a closer look at "ext4: Turn off multiple page-io submission by
>>>>> default"
>>>>
>>>> I tried to Google for mblk_io_submit but I didn't find anything
>>>> helpful.
>>>> Could you tell me how should I add this option in fstab and what
>>>> will be
>>>> its effect?
>>>
>>> As far as I understand that option regards writing, not reading. The
>>> symptoms I described occured while reading only.
>>>
>>
>> That's the only performance issue I am aware of in ext4 in recent time.
>> Why don't you try it and present some numbers in transfer ratio
>> (write, read)?
>
> Ok, I'll try to measure it in shell. Now I am building newest non-next
> kernel and the trial script is:
>
> #!/bin/bash
>
> uname -a
> mount
> cd /data/music
> time ls -d *
> cd -
>
> This is basically what mocp does when it enters my music directory,
> apart from displaying the results in ncurses based UI. Then I'll reboot
> with next kernel and run it again. Will it do?

Sorry for the desinformation, now I see that there must be some othe
things that mocp does because when I measured it I see that my initial
observaions were false. The script is attached, plain is the newest
ordinary kernel 2.6.37-rc7-git5, _1 file is the first run, _2 is the
second run. Similarily the next_ files, after mounting / with the option
in question. They show no big difference between the kernels.

Regards,

Piotr Hosowicz

--
Babcia rox! :
alek: przyszli do mnie jehowi dzisiaj, otworzy?a babcia
pate_q: i co?
alek: po 30 minutach rozmowy chcieli przej?? na chrze?cija?stwo
NP: Peter Green Splinter Group - Heart Of Stone
NB: 2.6.37-rc7-git5


Attachments:
next_1.txt (3.52 kB)
next_2.txt (3.52 kB)
plain_1.txt (3.50 kB)
plain_2.txt (3.50 kB)
test.sh (88.00 B)
Download all attachments

2010-12-28 15:10:16

by James Bottomley

[permalink] [raw]
Subject: Re: linux-next: Tree for December 27 (drivers/target)

On Mon, 2010-12-27 at 14:49 -0800, Nicholas A. Bellinger wrote:
> On Mon, 2010-12-27 at 11:57 -0800, Randy Dunlap wrote:
> > On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > [The mirroring on kernel.org is running slowly]
> > >
> > > Changes since 20101221:
> > >
> > > Linus' tree lost its build failure.
> >
> >
> > Hi Nick,
> >
> > Please test building target code when CONFIG_BLOCK is not enabled.
> >
> > When CONFIG_BLOCK is not enabled, drivers/target/ gets a boat load of build errors.
> >
> > Should TCM_IBLOCK depend on BLOCK? That fixes lots of the build errors,
> > but not all of them.
> >
> >
> > The header file include/target/target_core_base.h uses struct queue_limits,
> > so it should #include <linux/blkdev.h>.
> >
> >
>
> Added the missing include here:
>
> target: Add linux/blkdev.h include in target_core_base.h
> http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=e8bd07d3a525e71b424d308fc5084b89a6456bb2
>
> Thanks Randy!

Could you just do mod patches inline to the list, please? It's much
less convenient trying to pull them out of a web page.

Thanks,

James