* linux-next: proc tree build failure
From: Stephen Rothwell @ 2008-11-24 7:15 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-next, Ken Chen, Ingo Molnar, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
Hi Alexey,
Today's linux-next build (sparc64 allmodconfig) failed like this:
fs/proc/base.c:362: undefined reference to `save_stack_trace_tsk'
It has been failing like this for some time.
Caused by commit 788ff43b53179f3af8677d59c87104aff1f75bde ("proc:
add /proc/*/stack") which has been fixed up for MIPS, but needs another
fix for Sparc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: Tree for November 24
From: Stephen Rothwell @ 2008-11-24 7:05 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 6959 bytes --]
Hi all,
Changes since 20081121:
Undropped trees:
wireless
Dropped trees (temporarily):
net (build problem)
rr (build problem)
ttydev (build problem)
userns (it depends on creds)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
The ftrace tree gained a conflict against Linus' tree.
The net tree lost its 3 conflicts, a merge fix and its build failure, but
gained a new build failure and was dropped.
The rr tree gained a conflict against the genirq tree and also a build
failure and was dropped.
The ttydev tree was dropped due to an over the weekend build failure.
The cpu_alloc tree was dropped due to a long standing build failure.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-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,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 126 trees (counting Linus' and 15 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 Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and 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 sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
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/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
CONFLICT (content): Merge conflict in drivers/char/Makefile
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
CONFLICT (content): Merge conflict in kernel/trace/ftrace.c
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Applying net: async_tx merge fix
$ git reset --hard HEAD^
Merging mtd/master
Merging wireless/master
Applying net: async_tx merge fix
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/x86/kernel/io_apic.c
CONFLICT (content): Merge conflict in kernel/irq/manage.c
CONFLICT (content): Merge conflict in kernel/irq/proc.c
$ git reset --hard HEAD^
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
CONFLICT (content): Merge conflict in drivers/net/tg3.c
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_cred.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_globals.h
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.h
Merging lblnet/master
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in fs/proc/base.c
CONFLICT (content): Merge conflict in kernel/exit.c
Merging bdev/master
Merging dwmw2-iommu/master
Merging cpu_alloc/cpu_alloc
CONFLICT (content): Merge conflict in kernel/lockdep.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git reset --hard HEAD^
Merging cputime/cputime
Merging perfmon3/master
Merging osd/linux-next
Merging fatfs/master
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: build warning
From: Stephen Rothwell @ 2008-11-24 6:38 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-next, Cheng Renquan, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
Hi Neil,
Today's linux-next build (i386 defconfig) produced these warnings:
drivers/md/md.c: In function 'print_sb_1':
drivers/md/md.c:1678: warning: left shift count >= width of type
drivers/md/md.c:1702: warning: left shift count >= width of type
Caused by commit 8a11632aeb9ad49bbda3e2c6978b207c6aff1aa8 ("md: need
another print_sb for mdp_superblock_1").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: vme_scc.c breakage (was: Re: linux-next: Tree for November 21)
From: Brad Boyer @ 2008-11-24 6:08 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, Stephen Rothwell, linux-next, Linux/m68k
In-Reply-To: <alpine.DEB.1.00.0811240217030.18487@zirkon.biophys.uni-duesseldorf.de>
On Mon, Nov 24, 2008 at 02:55:42AM +0100, Michael Schmitz wrote:
> > We probably should have an SCC/ESCC core driver the way we have for
> > a lot of the other common chips like 8390 ethernet or ESP SCSI. I
> > know there's lots of systems with these chips that each have drivers.
>
> Didn't seem too many of those in drivers/serial ...
I must admit I didn't go count them.
> > Most of the m68k mac serial quirks are the same as the ones in the
> > pmac serial driver. There is only one interrupt for both ports, but
>
> According to my 2.2.25 source, SCC A is at interrupt number 33, SCC B is
> at 34. Did that change with tha A/UX interrupt style?
No, those are synthetic interrupt sources. If you look at the interrupt
code, there is a fake interrupt controller registered on IRQ 4 that
looks at the SCC status bits and triggers the correct interrupt. Take
a look at mac_scc_dispatch in arch/m68k/mac/macints.c for details. The
pmac_zilog code does it a little different by tying the two devices
together and only registering for one interrupt and passing them off.
> What seems to be true is all interrupt types for a given channel go to
> the same handler...
That is definitely true on any Mac. Apple was generally stingy with
interrupt sources. For example, some mac systems don't even have a
real IRQ per NuBus slot even though they do all at least have a way
to detect which slot asserted the interrupt.
> The platform device would need to have one interrupt number each for TX, RX,
> status and special condition for each channel, plus data/control ports forr
> each, plus flags. The Mac platform device would have only one interrupt per
> channel (and perhaps a flag indicating that).
I'm sure we could do something like that with flags.
> > built-in modems need enable/disable code for that on m68k macs
>
> Are there any Macs with builtin modems in the standard configuration?
It depends on what you mean by standard configuration. Some PowerBooks
shipped with internal modems, but I don't think there is any model
that always had one. It was an option on most later m68k PowerBooks
while most early ppc PowerBooks always had an internal modem.
> > There isn't much m68k mac specific, and I don't think the issues
> > you mention for Atari are issues on macs. The AV systems have
> > DMA but don't have a tx-dma channel for the second port. The one
> > interrupt is hooked up to IRQ 4, which means it doesn't go through
>
> This is on AV Macs only (because the PSC interrupts are at 32-35 there)?
The AV Macs are quite a bit different from an IRQ perspective. They
don't hook much of anything up directly, so the layout is slightly more
logical. In particular, the registration of mac_scc_dispatch to IRQ 4
is conditionalized on !psc_present to exclude the AV models. It's all
the models using VIA1 as the main interrupt controller that need it.
The SCC interrupt line is never hooked up to a VIA chip, but it is
connected to the PSC on AV macs and the SCC IOP on the IIfx. Sorry
if the way I wrote this was confusing.
> > We could probably do something along those lines, but I can't see
> > tying it directly to the platform bus. I think it would be better
> > to make a zilog SCC/ESCC core driver and write a driver for each
> > bus interface type the way the ESP driver now works. It just seems
> > simpler from a code maintenance perspective.
>
> I don't think using callbacks would be a clean way of handling this, so your
> idea may be better.
It's hard to say for sure without trying it to see how it turns out.
> VME and Atari used to use the same driver in 2.2 so that should still be
> possible now.
Seems reasonable.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 5:45 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger, sam
In-Reply-To: <20081123.212929.13595907.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
Hi Dave,
On Sun, 23 Nov 2008 21:29:29 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: David Miller <davem@davemloft.net>
> Date: Sun, 23 Nov 2008 21:23:39 -0800 (PST)
>
> > I'll try to get it turned back on,
>
> Ok the following seems to build on sparc64, so after some
> sparc 32-bit build tests I'll check this into sparc-next-2.6
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 5:38 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger, sam
In-Reply-To: <20081123.212339.131214270.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Sun, 23 Nov 2008 21:23:39 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Probably it didn't build for some obscure reason a long time
> ago. I'll try to get it turned back on, but better is to
> bring it in via drivers/Kconfig don't you think? :-)
Only if you test build all the other architectures that currently don't
include it. :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: cpu_alloc tree build failure
From: Stephen Rothwell @ 2008-11-24 5:36 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
Hi Christoph,
I have dropped the cpu_alloc tree for today (it is my day for being hard
on people :-)) because it breaks the build on a few architectures and the
fix has been know since at least Nov 7 (when you published a patch that
doesn't appear in your tree).
If this is caused by an interaction with another tree (and I don't think
it is), let me know and I will carry the patch. Otherwise you need to
fix the cpu_alloc tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-24 5:29 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger, sam
In-Reply-To: <20081123.212339.131214270.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 23 Nov 2008 21:23:39 -0800 (PST)
> I'll try to get it turned back on,
Ok the following seems to build on sparc64, so after some
sparc 32-bit build tests I'll check this into sparc-next-2.6
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 41c4cd2..10945c3 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -435,24 +435,6 @@ config MCA
help
MCA is not supported.
-config PCMCIA
- tristate
- ---help---
- Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
- computer. These are credit-card size devices such as network cards,
- modems or hard drives often used with laptops computers. There are
- actually two varieties of these cards: the older 16 bit PCMCIA cards
- and the newer 32 bit CardBus cards. If you want to use CardBus
- cards, you need to say Y here and also to "CardBus support" below.
-
- To use your PC-cards, you will need supporting software from David
- Hinds' pcmcia-cs package (see the file <file:Documentation/Changes>
- for location). Please also read the PCMCIA-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as modules, choose M here: the
- modules will be called pcmcia_core and ds.
-
config SBUS
bool
default y
@@ -497,6 +479,8 @@ config PCI_SYSCALL
source "drivers/pci/Kconfig"
+source "drivers/pcmcia/Kconfig"
+
config SUN_OPENPROMFS
tristate "Openprom tree appears in /proc/openprom"
help
^ permalink raw reply related
* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-24 5:23 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger, sam
In-Reply-To: <20081124162044.f3333fcf.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 24 Nov 2008 16:20:44 +1100
> Yeah, and including it does turn CONFIG_PCMCIA on. But I am genuinely
> curious as there is a CONFIG_PCMCIA entry (with a really ancient comment)
> in arch/sparc64/Kconfig, so why is that not sufficient to get
> CONFIG_PCMCIA turned on? There is clearly something lacking in my
> understanding ...
Probably it didn't build for some obscure reason a long time
ago. I'll try to get it turned back on, but better is to
bring it in via drivers/Kconfig don't you think? :-)
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 5:22 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger, Sam Ravnborg
In-Reply-To: <20081124162044.f3333fcf.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
Hi Dave,
On Mon, 24 Nov 2008 16:20:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Yeah, and including it does turn CONFIG_PCMCIA on. But I am genuinely
> curious as there is a CONFIG_PCMCIA entry (with a really ancient comment)
> in arch/sparc64/Kconfig, so why is that not sufficient to get
> CONFIG_PCMCIA turned on? There is clearly something lacking in my
> understanding ...
(Light dawns) I guess it is the lack of a prompt ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 5:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger, Sam Ravnborg
In-Reply-To: <20081123.210452.160784844.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
Hi Dave,
On Sun, 23 Nov 2008 21:04:52 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 24 Nov 2008 15:49:38 +1100
>
> > So I wonder what prevents CONFIG_PCMCIA being set on a sparc64
> > allmodconfig? Just looking at the Kconfig files, I thought it
> > would, but obviously not.
>
> drivers/Kconfig doesn't include drivers/pcmcia/Kconfig,
> each arch Kconfig has to do it explicitly
Yeah, and including it does turn CONFIG_PCMCIA on. But I am genuinely
curious as there is a CONFIG_PCMCIA entry (with a really ancient comment)
in arch/sparc64/Kconfig, so why is that not sufficient to get
CONFIG_PCMCIA turned on? There is clearly something lacking in my
understanding ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: ttydev tree build failure
From: Stephen Rothwell @ 2008-11-24 5:13 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 822 bytes --]
Hi Alan,
I have dropped the ttydev tree for today due to unresolved build issues on
m68k caused by a bad conversion of drivers/char/vme_scc.c in
tty-port-extract-cd causing these errors:
drivers/char/vme_scc.c:634: error: syntax error before 'volatile'
drivers/char/vme_scc.c:634: error: '__mptr' undeclared (first use in this function)
drivers/char/vme_scc.c:634: error: (Each undeclared identifier is reported only once
drivers/char/vme_scc.c:634: error: for each function it appears in.)
drivers/char/vme_scc.c:634: error: syntax error before ')' token
drivers/char/vme_scc.c:635: error: 'port' undeclared here (not in a function)
drivers/char/vme_scc.c:637: error: syntax error before 'return'
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-24 5:04 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger
In-Reply-To: <20081124154938.bac22cd5.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 24 Nov 2008 15:49:38 +1100
> So I wonder what prevents CONFIG_PCMCIA being set on a sparc64
> allmodconfig? Just looking at the Kconfig files, I thought it
> would, but obviously not.
drivers/Kconfig doesn't include drivers/pcmcia/Kconfig,
each arch Kconfig has to do it explicitly
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 4:49 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger
In-Reply-To: <20081123.202847.85900696.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
Hi Dave,
On Sun, 23 Nov 2008 20:28:47 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 24 Nov 2008 15:25:50 +1100
>
> > Sorry, no. If the build failure is caused by an interaction between two
> > trees in linux-next, then I will spend some time trying to fix it up.
> > However, a simple allmodconfig (even on sparc64, I think) build would
> > have shown you the failure *before* publishing your tree.
>
> Would not, I do an allmodconfig build on sparc64 before every
> push of the net-next-2.6 tree.
So I wonder what prevents CONFIG_PCMCIA being set on a sparc64
allmodconfig? Just looking at the Kconfig files, I thought it would, but
obviously not.
It means, of course, that that build doesn't test any of the possible
effects of network changes on the PCMCIA device drivers.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-24 4:28 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger
In-Reply-To: <20081124152550.6a06efa4.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 24 Nov 2008 15:25:50 +1100
> Sorry, no. If the build failure is caused by an interaction between two
> trees in linux-next, then I will spend some time trying to fix it up.
> However, a simple allmodconfig (even on sparc64, I think) build would
> have shown you the failure *before* publishing your tree.
Would not, I do an allmodconfig build on sparc64 before every
push of the net-next-2.6 tree.
That's why I'm so irritated by this.
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 4:25 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, shemminger
In-Reply-To: <20081123.195602.16120267.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
Hi Dave,
On Sun, 23 Nov 2008 19:56:02 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Can't you just revert the patch to fix the build instead? :-/
[I realise you are not being completely serious, but I am just taking the
opportunity to stat my position - don't take it personally].
Sorry, no. If the build failure is caused by an interaction between two
trees in linux-next, then I will spend some time trying to fix it up.
However, a simple allmodconfig (even on sparc64, I think) build would
have shown you the failure *before* publishing your tree.
This is me practising my new "Arrogant Bastard"(tm) style of teaching. :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-24 4:03 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger
In-Reply-To: <20081123.195602.16120267.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 23 Nov 2008 19:56:02 -0800 (PST)
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 24 Nov 2008 13:43:01 +1100
>
> > Caused by commit 4e4fd4e485ad63a9074ff09a9b53ffc7a5c594ec ("ne2k: convert
> > to net_device_ops").
> >
> > I have dropped the net tree again.
>
> Can't you just revert the patch to fix the build instead? :-/
Or wait the 5 friggin' minutes it took me to compose and
push out this obvious patch. It's not like we're not awake
at the same time :-/
axnet_cs: Fix build after net device ops ne2k conversion.
Commit 4e4fd4e485ad63a9074ff09a9b53ffc7a5c594ec ("ne2k: convert to
net_device_ops") exported some ei_* symbols from the 8390 library,
but the axnet_cs driver defines local static versions of the same
functions.
Rename them to avoid the namespace conflict.
Reported by Stephen Rothwell.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/pcmcia/axnet_cs.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/pcmcia/axnet_cs.c b/drivers/net/pcmcia/axnet_cs.c
index 2aca8df..c9890b4 100644
--- a/drivers/net/pcmcia/axnet_cs.c
+++ b/drivers/net/pcmcia/axnet_cs.c
@@ -904,7 +904,7 @@ int ei_debug = 1;
/* Index to functions. */
static void ei_tx_intr(struct net_device *dev);
static void ei_tx_err(struct net_device *dev);
-static void ei_tx_timeout(struct net_device *dev);
+static void axnet_tx_timeout(struct net_device *dev);
static void ei_receive(struct net_device *dev);
static void ei_rx_overrun(struct net_device *dev);
@@ -955,9 +955,9 @@ static int ax_open(struct net_device *dev)
#ifdef HAVE_TX_TIMEOUT
/* The card I/O part of the driver (e.g. 3c503) can hook a Tx timeout
- wrapper that does e.g. media check & then calls ei_tx_timeout. */
+ wrapper that does e.g. media check & then calls axnet_tx_timeout. */
if (dev->tx_timeout == NULL)
- dev->tx_timeout = ei_tx_timeout;
+ dev->tx_timeout = axnet_tx_timeout;
if (dev->watchdog_timeo <= 0)
dev->watchdog_timeo = TX_TIMEOUT;
#endif
@@ -1001,14 +1001,14 @@ static int ax_close(struct net_device *dev)
}
/**
- * ei_tx_timeout - handle transmit time out condition
+ * axnet_tx_timeout - handle transmit time out condition
* @dev: network device which has apparently fallen asleep
*
* Called by kernel when device never acknowledges a transmit has
* completed (or failed) - i.e. never posted a Tx related interrupt.
*/
-static void ei_tx_timeout(struct net_device *dev)
+static void axnet_tx_timeout(struct net_device *dev)
{
long e8390_base = dev->base_addr;
struct ei_device *ei_local = (struct ei_device *) netdev_priv(dev);
@@ -1045,14 +1045,14 @@ static void ei_tx_timeout(struct net_device *dev)
}
/**
- * ei_start_xmit - begin packet transmission
+ * axnet_start_xmit - begin packet transmission
* @skb: packet to be sent
* @dev: network device to which packet is sent
*
* Sends a packet to an 8390 network device.
*/
-static int ei_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static int axnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
long e8390_base = dev->base_addr;
struct ei_device *ei_local = (struct ei_device *) netdev_priv(dev);
@@ -1718,7 +1718,7 @@ static void axdev_setup(struct net_device *dev)
ei_local = (struct ei_device *)netdev_priv(dev);
spin_lock_init(&ei_local->page_lock);
- dev->hard_start_xmit = &ei_start_xmit;
+ dev->hard_start_xmit = &axnet_start_xmit;
dev->get_stats = get_stats;
dev->set_multicast_list = &set_multicast_list;
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-24 3:56 UTC (permalink / raw)
To: sfr; +Cc: linux-next, shemminger
In-Reply-To: <20081124134301.8aebd20f.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 24 Nov 2008 13:43:01 +1100
> Caused by commit 4e4fd4e485ad63a9074ff09a9b53ffc7a5c594ec ("ne2k: convert
> to net_device_ops").
>
> I have dropped the net tree again.
Can't you just revert the patch to fix the build instead? :-/
The net tree won't get much testing if every obscure driver build
failure makes the net tree get removed.
^ permalink raw reply
* linux-next: rr tree build failure
From: Stephen Rothwell @ 2008-11-24 3:31 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Mike Travis
Hi Rusty,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/kernel/irq.c: In function 'fixup_irqs':
arch/powerpc/kernel/irq.c:240: error: incompatible type for argument 2 of 'irq_desc[irq].chip->set_affinity'
arch/powerpc/sysdev/mpic.c: In function 'mpic_alloc':
arch/powerpc/sysdev/mpic.c:1069: warning: assignment from incompatible pointer type
arch/powerpc/sysdev/mpic.c:1074: warning: assignment from incompatible pointer type
arch/powerpc/platforms/pseries/xics.c:385: warning: initialization from incompatible pointer type
arch/powerpc/platforms/pseries/xics.c:394: warning: initialization from incompatible pointer type
arch/powerpc/platforms/pseries/xics.c: In function 'xics_migrate_irqs_away':
arch/powerpc/platforms/pseries/xics.c:864: error: incompatible type for argument 2 of 'desc->chip->set_affinity'
caused by commit 5b03e170d524383a34a89fd73ec9d1bda0922d63
("cpumask:irq-functions-take-cpumask_t-ptr") which changed the
set_affinity callback but didn't update all the instances.
I have dropped the rr tree again today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* linux-next: manual merge of the rr tree
From: Stephen Rothwell @ 2008-11-24 3:20 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Thomas Gleixner, Ingo Molnar, Mike Travis
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
kernel/irq/manage.c between commit
612e3684c1b7752d2890510e4f90115fd1eb2afb ("genirq: fix the affinity
setting in setup_irq") from the genirq tree and commit
5b03e170d524383a34a89fd73ec9d1bda0922d63
("cpumask:irq-functions-take-cpumask_t-ptr") from the rr tree.
I fixed it up (see below) and can carry it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc kernel/irq/manage.c
index 4358612,7dc7563..0000000
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@@ -123,9 -119,10 +119,10 @@@ int do_irq_select_affinity(unsigned in
* Preserve an userspace affinity setup, but make sure that
* one of the targets is online.
*/
- if (desc->status & IRQ_AFFINITY_SET) {
+ if (desc->status & (IRQ_AFFINITY_SET | IRQ_NO_BALANCING)) {
- if (cpus_intersects(desc->affinity, cpu_online_map))
- mask = desc->affinity;
+ if (cpumask_any_and(&desc->affinity, cpu_online_mask)
+ < nr_cpu_ids)
+ goto set_affinity;
else
desc->status &= ~IRQ_AFFINITY_SET;
}
^ permalink raw reply
* linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-24 2:43 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, Stephen Hemminger
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/net/pcmcia/axnet_cs.c:908: error: static declaration of 'ei_tx_timeout' follows non-static declaration
drivers/net/pcmcia/../8390.h:36: error: previous declaration of 'ei_tx_timeout' was here
drivers/net/pcmcia/axnet_cs.c:1056: error: static declaration of 'ei_start_xmit' follows non-static declaration
drivers/net/pcmcia/../8390.h:37: error: previous declaration of 'ei_start_xmit' was here
Caused by commit 4e4fd4e485ad63a9074ff09a9b53ffc7a5c594ec ("ne2k: convert
to net_device_ops").
I have dropped the net tree again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the ftrace tree
From: Stephen Rothwell @ 2008-11-24 2:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Steven Rostedt
In-Reply-To: <20081124021134.GA23669@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi Ingo,
On Mon, 24 Nov 2008 03:11:34 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> hm, latest tip/auto-ftrace-next has no merge commit with -git. But i
> reintegrated it about an hour before you sent this mail - maybe you've
> got the old branch still?
Probably, but I expect everyone knows my schedule by now (my offer to
DaveM to sleep in was not serious :-)).
Anyway, I assume it is fixed for tomorrow and that is all I need, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the ftrace tree
From: Ingo Molnar @ 2008-11-24 2:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Steven Rostedt
In-Reply-To: <20081124111112.fa876dce.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the ftrace tree got a conflict in
> kernel/trace/ftrace.c between commits
> 820432783190b4096499e38a4a4d7095c511913d ("ftrace: make filtered
> functions effective on setting") and
> 32464779a1b8c15e9aa9aa0306b2f735080df9d8 ("ftrace: fix dyn ftrace filter
> selection") from Linus' tree and commit ftrace_startup ("ftrace: add
> quick function trace stop") from the ftrace tree.
>
> I fixed it up (see below - which may not be correct) but it needs to be
> fixed in the ftrace tree.
hm, latest tip/auto-ftrace-next has no merge commit with -git. But i
reintegrated it about an hour before you sent this mail - maybe you've
got the old branch still?
Ingo
^ permalink raw reply
* Re: vme_scc.c breakage (was: Re: linux-next: Tree for November 21)
From: Michael Schmitz @ 2008-11-24 1:55 UTC (permalink / raw)
To: Brad Boyer; +Cc: Geert Uytterhoeven, Stephen Rothwell, linux-next, Linux/m68k
In-Reply-To: <20081123092222.GA4094@cynthia.pants.nu>
Hi,
> > Atari SCC variants have their own quirks, so something more configurable
> > will be needed.
>
> We probably should have an SCC/ESCC core driver the way we have for
> a lot of the other common chips like 8390 ethernet or ESP SCSI. I
> know there's lots of systems with these chips that each have drivers.
Didn't seem too many of those in drivers/serial ...
> > What are the quirks the m68k mac SCC driver woukd add? From memory, I have this
>
> Most of the m68k mac serial quirks are the same as the ones in the
> pmac serial driver. There is only one interrupt for both ports, but
According to my 2.2.25 source, SCC A is at interrupt number 33, SCC B is at 34.
Did that change with tha A/UX interrupt style?
What seems to be true is all interrupt types for a given channel go to the same
handler...
The platform device would need to have one interrupt number each for TX, RX,
status and special condition for each channel, plus data/control ports forr
each, plus flags. The Mac platform device would have only one interrupt per
channel (and perhaps a flag indicating that).
> the drivers do funny things to make it look mostly like each port
> has its own interrupt. There are some odd things about how Apple
> hooked up the hardware flow control. I suspect that any models with
Right you are ...
> built-in modems need enable/disable code for that on m68k macs
Are there any Macs with builtin modems in the standard configuration?
> There isn't much m68k mac specific, and I don't think the issues
> you mention for Atari are issues on macs. The AV systems have
> DMA but don't have a tx-dma channel for the second port. The one
> interrupt is hooked up to IRQ 4, which means it doesn't go through
This is on AV Macs only (because the PSC interrupts are at 32-35 there)?
> > Can the platform bus device code define architecture specific init callbacks
> > to hide this?
>
> We could probably do something along those lines, but I can't see
> tying it directly to the platform bus. I think it would be better
> to make a zilog SCC/ESCC core driver and write a driver for each
> bus interface type the way the ESP driver now works. It just seems
> simpler from a code maintenance perspective.
I don't think using callbacks would be a clean way of handling this, so your
idea may be better.
VME and Atari used to use the same driver in 2.2 so that should still be
possible now.
Michael
^ permalink raw reply
* linux-next: manual merge of the ftrace tree
From: Stephen Rothwell @ 2008-11-24 0:11 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: linux-next, Steven Rostedt
Hi all,
Today's linux-next merge of the ftrace tree got a conflict in
kernel/trace/ftrace.c between commits
820432783190b4096499e38a4a4d7095c511913d ("ftrace: make filtered
functions effective on setting") and
32464779a1b8c15e9aa9aa0306b2f735080df9d8 ("ftrace: fix dyn ftrace filter
selection") from Linus' tree and commit ftrace_startup ("ftrace: add
quick function trace stop") from the ftrace tree.
I fixed it up (see below - which may not be correct) but it needs to be
fixed in the ftrace tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc kernel/trace/ftrace.c
index 78db083,beb21a5..0000000
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@@ -526,8 -560,9 +553,8 @@@ static void ftrace_startup(void
return;
mutex_lock(&ftrace_start_lock);
- ftrace_start++;
+ ftrace_start_up++;
- if (ftrace_start_up == 1)
- command |= FTRACE_ENABLE_CALLS;
+ command |= FTRACE_ENABLE_CALLS;
if (saved_ftrace_func != ftrace_trace_function) {
saved_ftrace_func = ftrace_trace_function;
@@@ -1181,7 -1212,7 +1208,7 @@@ ftrace_regex_release(struct inode *inod
mutex_lock(&ftrace_sysctl_lock);
mutex_lock(&ftrace_start_lock);
- if (ftrace_start && ftrace_enabled)
- if (iter->filtered && ftrace_start_up && ftrace_enabled)
++ if (ftrace_start_up && ftrace_enabled)
ftrace_run_update_code(FTRACE_ENABLE_CALLS);
mutex_unlock(&ftrace_start_lock);
mutex_unlock(&ftrace_sysctl_lock);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox