Hi all,
Changes since next-20080704:
Temporarily dropped tree: ttydev (since it would not import on top of any
tree I have)
The usb.current gained a white space conflict against Linus' tree (which I
assume will be gone as soon as Greg rebases his tree).
The usb tree gained a conflict against Linus' tree.
The tip-core tree gained a conflict against Linus' tree.
The sched tree lost a build fix patch.
The x86 tree lost a conflict against Linus' tree but gained two against
the ftrace tree.
The pci tree gained a conflict against the driver-core tree and needed
another build fix patch.
The kbuild tree needed a commit reverted to fix the build.
The acpi tree gained three m conflicts against the pci tree.
The scsi tree gained 2 conflicts against the driver-core tree.
the powerpc tree lost a conflict against the i2c tree.
The net tree lost a conflict against Linus' tree but gained three more
against the wireless-current, pci and x86 trees.
The wireless tree lost its 2 conflicts.
The trivial tree gained a conflict against Linus' tree.
The firmware tree gained a conflict against Linus' tree.
The battery tree gained 2 conflicts against the arm tree.
The generic-ipi tree lost a conflict and a build fix patch.
The mfd tree gained a conflict against Linus' tree.
The hdlc tree gained 2 conflicts against the net tree.
I have also applied the following patches for known problems (I assume
that these will be merged into their appropriate trees shortly):
fix "ftrace: store mcount address in rec->ip"
linux-next: zero based percpu build error on s390
sparc64: sysdev API change fallout
The patches are no longer applied:
NFS: Fix the mount protocol defaults for binary mounts (applies,
but breaks the build)
ttydev: fix pamc_zilog for tty pointer move
ttydev: sparc fix for tty move
ttydev: sparc32 fix for tty move
atmel_serial: Fix tty_port breakage (the ttydev tree is not
included today)
linux-next: generic helpers for arch IPI function calls build bug / s390
(no longer needed)
I have also reverted 2 commits from the mmc tree because one of them
broke the powerpc allyesconfig build.
I also accidentally removed the merge log before committing it to the
tree but the summary is still below.
----------------------------------------------------------------------------
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, 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 104 trees (counting Linus' and 14 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 [email protected]
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
CONFLICT (content): Merge conflict in drivers/usb/core/hcd.c
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging quilt/driver-core
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/core/hub.c
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in lib/vsprintf.c
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
CONFLICT (content): Merge conflict in kernel/Makefile
CONFLICT (content): Merge conflict in kernel/sched.c
CONFLICT (content): Merge conflict in kernel/sched_rt.c
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/x86/kernel/entry_32.S
CONFLICT (content): Merge conflict in arch/x86/kernel/entry_64.S
CONFLICT (content): Merge conflict in arch/x86/kernel/process_32.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c
CONFLICT (content): Merge conflict in drivers/base/topology.c
CONFLICT (content): Merge conflict in include/asm-x86/irqflags.h
Merging pci/linux-next
CONFLICT (content): Merge conflict in arch/sparc64/kernel/pci.c
CONFLICT (delete/modify): arch/x86/kernel/setup_64.c deleted in HEAD and modified in pci/linux-next. Version pci/linux-next of arch/x86/kernel/setup_64.c left in tree.
CONFLICT (content): Merge conflict in arch/x86/pci/irq.c
CONFLICT (content): Merge conflict in arch/x86/pci/pci.h
CONFLICT (content): Merge conflict in include/linux/device.h
Applying pci: usb fixup 1
Applying pci: include linux/pm_wakeup.h for device_set_wakeup_capable
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/i2c-core.c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
CONFLICT (content): Merge conflict in drivers/media/video/Kconfig
Applying v4l-dvb: class_for_each_device API change fallout
Merging s390/features
CONFLICT (content): Merge conflict in drivers/s390/block/dasd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_eckd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_fba.c
CONFLICT (content): Merge conflict in drivers/s390/char/tape_core.c
CONFLICT (content): Merge conflict in drivers/s390/cio/device_fsm.c
CONFLICT (content): Merge conflict in drivers/s390/cio/qdio.c
CONFLICT (content): Merge conflict in drivers/s390/net/claw.c
CONFLICT (content): Merge conflict in drivers/s390/net/ctcm_main.c
CONFLICT (content): Merge conflict in drivers/s390/net/lcs.c
CONFLICT (content): Merge conflict in drivers/s390/net/netiucv.c
Merging sh/master
Merging jfs/next
Merging kbuild/master
Created commit 9aeede5: Revert "kconfig: normalize int/hex values"
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in arch/ia64/kernel/process.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process.c
CONFLICT (content): Merge conflict in arch/x86/kernel/srat_32.c
CONFLICT (content): Merge conflict in drivers/acpi/processor_core.c
CONFLICT (content): Merge conflict in drivers/acpi/processor_throttling.c
CONFLICT (content): Merge conflict in drivers/acpi/sleep/main.c
CONFLICT (content): Merge conflict in drivers/pci/pci.c
CONFLICT (content): Merge conflict in drivers/pci/pci.h
CONFLICT (content): Merge conflict in include/acpi/acpi_bus.h
CONFLICT (content): Merge conflict in include/asm-ia64/processor.h
CONFLICT (content): Merge conflict in include/asm-x86/processor.h
Merging blackfin/for-linus
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in net/sunrpc/svc.c
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/master
Merging kvm/master
Merging dlm/next
Merging scsi/master
CONFLICT (content): Merge conflict in drivers/s390/scsi/zfcp_aux.c
CONFLICT (content): Merge conflict in drivers/s390/scsi/zfcp_def.h
Applying scsi: fix fallout from the class_find_device API change
Applying scsi: fix fallout from KOBJ_NAME_LEN removal
Merging ia64/test
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging selinux/for-akpm
Merging quilt/m68k
Merging powerpc/powerpc-next
CONFLICT (content): Merge conflict in drivers/macintosh/mediabay.c
Merging lblnet/master
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging security-testing/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt
CONFLICT (content): Merge conflict in arch/x86/configs/x86_64_defconfig
CONFLICT (content): Merge conflict in drivers/net/fs_enet/fs_enet-main.c
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-3945.c
CONFLICT (content): Merge conflict in drivers/pci/pci-acpi.c
Merging sparc/master
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/vfs-2.6.25
Merging sound/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/kernel/time.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-yl-9200.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in drivers/char/hvc_console.h
CONFLICT (content): Merge conflict in kernel/stop_machine.c
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
CONFLICT (content): Merge conflict in drivers/net/ps3_gelic_wireless.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_attr.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_def.h
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mbx.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mid.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_os.c
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/nfs/file.c
Merging trivial/next
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/for_andrew
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/atm/Makefile
CONFLICT (content): Merge conflict in drivers/char/ip2/ip2main.c
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_3410.h left in tree.
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_5052.h left in tree.
CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c
CONFLICT (content): Merge conflict in include/linux/firmware.h
CONFLICT (content): Merge conflict in sound/pci/Kconfig
CONFLICT (content): Merge conflict in sound/pci/maestro3.c
CONFLICT (content): Merge conflict in sound/pci/ymfpci/ymfpci_main.c
Merging pcmcia/master
Merging battery/master
CONFLICT (content): Merge conflict in drivers/power/Kconfig
CONFLICT (content): Merge conflict in drivers/power/Makefile
Merging leds/for-mm
Merging backlight/for-mm
CONFLICT (content): Merge conflict in drivers/video/backlight/Kconfig
CONFLICT (content): Merge conflict in drivers/video/backlight/Makefile
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Merging md/for-next
Merging cris/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in include/asm-x86/pgtable.h
CONFLICT (content): Merge conflict in kernel/sysctl.c
Merging generic-ipi/auto-generic-ipi-next
CONFLICT (content): Merge conflict in arch/powerpc/mm/slice.c
CONFLICT (content): Merge conflict in arch/s390/kernel/time.c
CONFLICT (content): Merge conflict in arch/x86/kvm/vmx.c
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in net/iucv/iucv.c
CONFLICT (content): Merge conflict in virt/kvm/kvm_main.c
Applying generic-ipi: powerpc fallout fixes
Merging mips/mips-for-linux-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging hdlc/hdlc-next
CONFLICT (content): Merge conflict in drivers/net/wan/cosa.c
CONFLICT (content): Merge conflict in drivers/net/wan/hdlc_fr.c
CONFLICT (content): Merge conflict in drivers/net/wan/pc300_drv.c
Applying linux-next: zero based percpu build error on s390
Created commit 67849ef: Revert "mmc: fix spares errors of sdhci.c"
Created commit 57488a6: Revert "sdhci: graceful handling of bad addresses"
Applying sparc64: sysdev API change fallout
drivers/built-in.o: In function `usb_kbd_probe':
usbkbd.c:(.text+0x1457c9): undefined reference to `usbhid_lookup_quirk'
drivers/built-in.o: In function `usb_mouse_probe':
usbmouse.c:(.text+0x14603c): undefined reference to `usbhid_lookup_quirk'
make[1]: *** [.tmp_vmlinux1] Error 1
from (partial config):
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
CONFIG_HIDRAW=y
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT_POWERBOOK=y
CONFIG_HID_FF=y
# CONFIG_HID_PID is not set
CONFIG_LOGITECH_FF=y
CONFIG_LOGIRUMBLEPAD2_FF=y
# CONFIG_PANTHERLORD_FF is not set
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=y
CONFIG_USB_MOUSE=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
(for Alan :)
drivers/built-in.o: In function `ne_drv_resume':
ne.c:(.text+0xc9902): undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_block_output':
ne.c:(.text+0xc9c31): undefined reference to `NS8390_init'
drivers/built-in.o: In function `ne_probe1':
ne.c:(.init.text+0xbbb3): undefined reference to `NS8390_init'
drivers/built-in.o: In function `hp_probe1':
hp.c:(.init.text+0xc15a): undefined reference to `NS8390_init'
config attached.
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Tue, 8 Jul 2008 11:35:29 -0700
Randy Dunlap <[email protected]> wrote:
> (for Alan :)
>
> drivers/built-in.o: In function `ne_drv_resume':
> ne.c:(.text+0xc9902): undefined reference to `NS8390_init'
> drivers/built-in.o: In function `ne_block_output':
> ne.c:(.text+0xc9c31): undefined reference to `NS8390_init'
> drivers/built-in.o: In function `ne_probe1':
> ne.c:(.init.text+0xbbb3): undefined reference to `NS8390_init'
> drivers/built-in.o: In function `hp_probe1':
> hp.c:(.init.text+0xc15a): undefined reference to `NS8390_init'
beats me... my ne.c doesn't reference NS8390_init at all. The patch has
been going around for so long I've really lost track of what happened to
it over the many months.
My tree has NS8390p_init in both of those drivers and no reference to
NS8390_init at all.
Alan
Diff between my tree 8390 bits and linux-next ones
8390: diff between next and my driver
From: Alan Cox <[email protected]>
Please try this and if it sorts it fold it into the driver. This is a diff
between my tree and the linux-next tree
---
drivers/net/hp-plus.c | 2 +-
drivers/net/hp.c | 2 +-
drivers/net/ne.c | 8 ++++----
drivers/net/wd.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
index c2c4f49..8239939 100644
--- a/drivers/net/hp-plus.c
+++ b/drivers/net/hp-plus.c
@@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
}
outw(Perf_Page, ioaddr + HP_PAGING);
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
/* Leave the 8390 and HP chip reset. */
outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);
diff --git a/drivers/net/hp.c b/drivers/net/hp.c
index 8281209..0a8c649 100644
--- a/drivers/net/hp.c
+++ b/drivers/net/hp.c
@@ -389,7 +389,7 @@ static void __init
hp_init_card(struct net_device *dev)
{
int irq = dev->irq;
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
outb_p(irqmap[irq&0x0f] | HP_RUN,
dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
return;
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index 1412697..4a8a4b1 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
}
/* Read the 16 bytes of station address PROM.
- We must first initialize registers, similar to NS8390_init(eifdev, 0).
+ We must first initialize registers, similar to NS8390p_init(eifdev, 0).
We can't reliably read the SAPROM address without this.
(I learned the hard way!). */
{
@@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = eip_poll;
#endif
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
ret = register_netdev(dev);
if (ret)
@@ -794,7 +794,7 @@ retry:
if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
ne_reset_8390(dev);
- NS8390_init(dev,1);
+ NS8390p_init(dev,1);
break;
}
@@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)
if (netif_running(dev)) {
ne_reset_8390(dev);
- NS8390_init(dev, 1);
+ NS8390p_init(dev, 1);
netif_device_attach(dev);
}
return 0;
diff --git a/drivers/net/wd.c b/drivers/net/wd.c
index fa14255..6f9aa16 100644
--- a/drivers/net/wd.c
+++ b/drivers/net/wd.c
@@ -337,7 +337,7 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr)
#ifdef CONFIG_NET_POLL_CONTROLLER
dev->poll_controller = ei_poll;
#endif
- NS8390_init(dev, 0);
+ NS8390p_init(dev, 0);
#if 1
/* Enable interrupt generation on softconfig cards -- M.U */
On Tue, 8 Jul 2008 19:35:13 +0100 Alan Cox wrote:
> Diff between my tree 8390 bits and linux-next ones
>
> 8390: diff between next and my driver
>
> From: Alan Cox <[email protected]>
>
> Please try this and if it sorts it fold it into the driver. This is a diff
> between my tree and the linux-next tree
Yes, that's good. Thanks/Ack.
> ---
>
> drivers/net/hp-plus.c | 2 +-
> drivers/net/hp.c | 2 +-
> drivers/net/ne.c | 8 ++++----
> drivers/net/wd.c | 2 +-
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
>
> diff --git a/drivers/net/hp-plus.c b/drivers/net/hp-plus.c
> index c2c4f49..8239939 100644
> --- a/drivers/net/hp-plus.c
> +++ b/drivers/net/hp-plus.c
> @@ -262,7 +262,7 @@ static int __init hpp_probe1(struct net_device *dev, int ioaddr)
> }
>
> outw(Perf_Page, ioaddr + HP_PAGING);
> - NS8390_init(dev, 0);
> + NS8390p_init(dev, 0);
> /* Leave the 8390 and HP chip reset. */
> outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION);
>
> diff --git a/drivers/net/hp.c b/drivers/net/hp.c
> index 8281209..0a8c649 100644
> --- a/drivers/net/hp.c
> +++ b/drivers/net/hp.c
> @@ -389,7 +389,7 @@ static void __init
> hp_init_card(struct net_device *dev)
> {
> int irq = dev->irq;
> - NS8390_init(dev, 0);
> + NS8390p_init(dev, 0);
> outb_p(irqmap[irq&0x0f] | HP_RUN,
> dev->base_addr - NIC_OFFSET + HP_CONFIGURE);
> return;
> diff --git a/drivers/net/ne.c b/drivers/net/ne.c
> index 1412697..4a8a4b1 100644
> --- a/drivers/net/ne.c
> +++ b/drivers/net/ne.c
> @@ -355,7 +355,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
> }
>
> /* Read the 16 bytes of station address PROM.
> - We must first initialize registers, similar to NS8390_init(eifdev, 0).
> + We must first initialize registers, similar to NS8390p_init(eifdev, 0).
> We can't reliably read the SAPROM address without this.
> (I learned the hard way!). */
> {
> @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_device *dev, unsigned long ioaddr)
> #ifdef CONFIG_NET_POLL_CONTROLLER
> dev->poll_controller = eip_poll;
> #endif
> - NS8390_init(dev, 0);
> + NS8390p_init(dev, 0);
>
> ret = register_netdev(dev);
> if (ret)
> @@ -794,7 +794,7 @@ retry:
> if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
> printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
> ne_reset_8390(dev);
> - NS8390_init(dev,1);
> + NS8390p_init(dev,1);
> break;
> }
>
> @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform_device *pdev)
>
> if (netif_running(dev)) {
> ne_reset_8390(dev);
> - NS8390_init(dev, 1);
> + NS8390p_init(dev, 1);
> netif_device_attach(dev);
> }
> return 0;
> diff --git a/drivers/net/wd.c b/drivers/net/wd.c
> index fa14255..6f9aa16 100644
> --- a/drivers/net/wd.c
> +++ b/drivers/net/wd.c
> @@ -337,7 +337,7 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr)
> #ifdef CONFIG_NET_POLL_CONTROLLER
> dev->poll_controller = ei_poll;
> #endif
> - NS8390_init(dev, 0);
> + NS8390p_init(dev, 0);
>
> #if 1
> /* Enable interrupt generation on softconfig cards -- M.U */
> --
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
Hi Ingo,
On Tuesday, 8 of July 2008, Stephen Rothwell wrote:
> Hi all,
>
> Changes since next-20080704:
>
> Temporarily dropped tree: ttydev (since it would not import on top of any
> tree I have)
>
> The usb.current gained a white space conflict against Linus' tree (which I
> assume will be gone as soon as Greg rebases his tree).
>
> The usb tree gained a conflict against Linus' tree.
>
> The tip-core tree gained a conflict against Linus' tree.
>
> The sched tree lost a build fix patch.
>
> The x86 tree lost a conflict against Linus' tree but gained two against
> the ftrace tree.
Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
e38502eb8aa82314d5ab0eba45f50e6790dadd88
("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
don't work on x86_64, because acpi_dmi_table[] depends on __i386__.
Moreover, if you make them work (by removing that dependency), they hang my
nx6325 solid early during boot.
The revert patch is appended for your convenience. ;-)
Thanks,
Rafael
---
arch/x86/kernel/acpi/boot.c | 47 --------------------------------------------
1 file changed, 47 deletions(-)
Index: linux-next/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-next.orig/arch/x86/kernel/acpi/boot.c
+++ linux-next/arch/x86/kernel/acpi/boot.c
@@ -83,8 +83,6 @@ int acpi_lapic;
int acpi_ioapic;
int acpi_strict;
-static int disable_irq0_through_ioapic __initdata;
-
u8 acpi_sci_flags __initdata;
int acpi_sci_override_gsi __initdata;
int acpi_skip_timer_override __initdata;
@@ -996,10 +994,6 @@ mp_override_legacy_irq(u8 bus_irq, u8 po
int pin;
struct mp_config_intsrc mp_irq;
- /* Skip the 8254 timer interrupt (IRQ 0) if requested. */
- if (bus_irq == 0 && disable_irq0_through_ioapic)
- return;
-
/*
* Convert 'gsi' to 'ioapic.pin'.
*/
@@ -1066,10 +1060,6 @@ static void __init mp_config_acpi_legacy
for (i = 0; i < 16; i++) {
int idx;
- /* Skip the 8254 timer interrupt (IRQ 0) if requested. */
- if (i == 0 && disable_irq0_through_ioapic)
- continue;
-
for (idx = 0; idx < mp_irq_entries; idx++) {
struct mp_config_intsrc *irq = mp_irqs + idx;
@@ -1429,17 +1419,6 @@ static int __init force_acpi_ht(const st
}
/*
- * Don't register any I/O APIC entries for the 8254 timer IRQ.
- */
-static int __init
-dmi_disable_irq0_through_ioapic(const struct dmi_system_id *d)
-{
- pr_notice("%s detected: disabling IRQ 0 through I/O APIC\n", d->ident);
- disable_irq0_through_ioapic = 1;
- return 0;
-}
-
-/*
* If your system is blacklisted here, but you find that acpi=force
* works for you, please contact [email protected]
*/
@@ -1606,32 +1585,6 @@ static struct dmi_system_id __initdata a
DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
},
},
- /*
- * HP laptops which use a DSDT reporting as HP/SB400/10000,
- * which includes some code which overrides all temperature
- * trip points to 16C if the INTIN2 input of the I/O APIC
- * is enabled. This input is incorrectly designated the
- * ISA IRQ 0 via an interrupt source override even though
- * it is wired to the output of the master 8259A and INTIN0
- * is not connected at all. Abandon any attempts to route
- * IRQ 0 through the I/O APIC therefore.
- */
- {
- .callback = dmi_disable_irq0_through_ioapic,
- .ident = "HP NX6125 laptop",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6125"),
- },
- },
- {
- .callback = dmi_disable_irq0_through_ioapic,
- .ident = "HP NX6325 laptop",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
- },
- },
{}
};
On Tue, 8 Jul 2008, Randy Dunlap wrote:
> drivers/built-in.o: In function `usb_kbd_probe':
> usbkbd.c:(.text+0x1457c9): undefined reference to `usbhid_lookup_quirk'
> drivers/built-in.o: In function `usb_mouse_probe':
> usbmouse.c:(.text+0x14603c): undefined reference to `usbhid_lookup_quirk'
> make[1]: *** [.tmp_vmlinux1] Error 1
This got introduced by Jiri's
HID: fix quirk handling in usbmouse/kbd
Added to CC (and added also Pascal).
The dependency of usbkbd/usbmouse on usbhid is strange anyway. I'd
probably remove the whole quirk lookup thing from usbkbd/usbmouse drivers.
They introduce this ugly dependency, which is not worth it I guess. Also
usbkbd/usbmouse drivers are not needed in the vast majority of cases
anyway, and they shouldn't be loaded in standard configurations at all.
--
Jiri Kosina
SUSE Labs
On Wed, 9 Jul 2008, Rafael J. Wysocki wrote:
> Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
> ("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
> e38502eb8aa82314d5ab0eba45f50e6790dadd88
> ("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
> don't work on x86_64, because acpi_dmi_table[] depends on __i386__.
>
> Moreover, if you make them work (by removing that dependency), they hang my
> nx6325 solid early during boot.
I have build an x86-64 cross-compiler now and can test 64-bit kernels.
I have tested the patches you have requested to be reverted in a 64-bit
configuration now and discovered the following problems elsewhere:
1. Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for
the "8259A Virtual Wire" through the local APIC timer configuration
does not fully configure the relevant irq_chip structure. Instead it
relies on the preceding I/O APIC code to have set it up, which does not
happen if the I/O APIC variants have not been tried. I think this is
the reason of your hang.
2. As mentioned in the other mail, there is no such entity as ISA IRQ2.
The ACPI spec does not make it explicitly clear, but does not preclude
it either -- all it says is ISA legacy interrupts are identity mapped
by default (subject to overrides), but it does not state whether IRQ2
exists or not. As a result if there is no IRQ0 override, then IRQ2 is
normally initialised as an ISA interrupt, which implies an
edge-triggered line, which is unmasked by default as this is what we do
for edge-triggered I/O APIC interrupts so as not to miss an edge.
To the best of my knowledge it is useless, as IRQ2 has not been in use
since the PC/AT as back then it was taken by the 8259A cascade
interrupt to the slave, with the line posiotion in the slot rerouted to
newly-created IRQ9. No device could thus make use of this line with
the pair of 8259A chips. Now in theory INTIN2 of the I/O APIC may be
usable, but the interrupt of the device wired to it would not be
available in the PIC mode at all, so I seriously doubt if anybody
decided to reuse it for a regular device (anybody please feel free to
prove me otherwise).
However there are two common uses of INTIN2. One is for IRQ0, with an
ACPI interrupt override (or its equivalent in the MP table). But in
this case IRQ2 is gone entirely with INTIN0 left vacant. The other one
is for an 8959A ExtINTA cascade. In this case IRQ0 goes to INTIN0 and
if ACPI is used INTIN2 is assumed to be IRQ2 (there is no override and
ACPI has no way to report ExtINTA interrupts). This is where a problem
happens.
The problem is INTIN2 is configured as a native APIC interrupt, with a
vector assigned and the mask cleared. And the line may indeed get
active and inject interrupts if the master 8959A has its timer
interrupt enabled (it might happen for other interrupts too, but they
are normally masked in the process of rerouting them to the I/O APIC).
There are two cases where it will happen:
* When the I/O APIC NMI watchdog is enabled. This is actually a
misnomer as the watchdog pulses are delivered through the 8259A to
the LINT0 inputs of all the local APICs in the system. The
implication is the output of the master 8259A goes high and low
repeatedly, signalling interrupts to INTIN2 which is enabled too!
[The origin of the name is I think for a brief period during the
development we had a capability in our code to configure the watchdog
to use an I/O APIC input; that would be INTIN2 in this scenario.]
* When the native route of IRQ0 via INTIN0 fails for whatever reason --
as it happens with the system considered here. In this scenario the
timer pulse is delivered through the 8259A to LINT0 input of the
local APIC of the bootstrap processor, quite similarly to how is done
for the watchdog described above. The result is, again, INTIN2
receives these pulses too. Rafael's system used to escape this
scenario, because an incorrect IRQ0 override would occupy INTIN2 and
prevent it from being unmasked.
My conclusion is IRQ2 should be excluded from configuration in all the
cases and the current exception for ACPI systems should be lifted. The
reason being the exception not only being useless, but harmful as well.
I have patches ready to address both issues, but I will test them against
linux-next yet, to avoid any dissynchronisation that may happen similar to
some recent experiences. I shall post the patches later today. At that
point 0b3d81ad4f765513347a04434efc15cbdc4e1c54 and
e38502eb8aa82314d5ab0eba45f50e6790dadd88 should be safe to bring back.
Maciej
On Wed, Jul 09, 2008 at 03:17:58PM +0100, Maciej W. Rozycki wrote:
> On Wed, 9 Jul 2008, Rafael J. Wysocki wrote:
>
> > Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
> > ("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
> > e38502eb8aa82314d5ab0eba45f50e6790dadd88
> > ("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
> > don't work on x86_64, because acpi_dmi_table[] depends on __i386__.
> >
> > Moreover, if you make them work (by removing that dependency), they hang my
> > nx6325 solid early during boot.
>
> I have build an x86-64 cross-compiler now and can test 64-bit kernels.
> I have tested the patches you have requested to be reverted in a 64-bit
> configuration now and discovered the following problems elsewhere:
>
> 1. Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for
> the "8259A Virtual Wire" through the local APIC timer configuration
> does not fully configure the relevant irq_chip structure. Instead it
> relies on the preceding I/O APIC code to have set it up, which does not
> happen if the I/O APIC variants have not been tried. I think this is
> the reason of your hang.
FYI, I looked further into the missing interrupt problem (testing on
64-bit, with Rafael's patch version and "Virtual Wire Mode" for the
timer IRQ).
Just before the weird behaviour I have two log entries:
APIC error on CPU1: 00(40)
APIC error on CPU0: 00(40)
AFAIK 0x40 is "Illegal Register Address" error:
"Illegal Register Address (IRA)Bit 7. The IRA bit when set to 1
indicates that an access to an unimplemented register location within
the local APIC register range (APIC Base Address + 4 Kbytes) was
attempted."
I've tried to track down who is responsible for that access. But I
didn't find the offender yet. Maybe it's Linux or some SMM stuff?
Don't know.
Right after those messages no interrupts from PIT/PIC (which should be
"virtual wired" to LVT0 of CPU0) are received anymore. I dumped PIC
and local APIC settings but I did not find any suspicious things here.
> 2. As mentioned in the other mail, there is no such entity as ISA IRQ2.
> The ACPI spec does not make it explicitly clear, but does not preclude
> it either -- all it says is ISA legacy interrupts are identity mapped
> by default (subject to overrides), but it does not state whether IRQ2
> exists or not. As a result if there is no IRQ0 override, then IRQ2 is
> normally initialised as an ISA interrupt, which implies an
> edge-triggered line, which is unmasked by default as this is what we do
> for edge-triggered I/O APIC interrupts so as not to miss an edge.
>
> To the best of my knowledge it is useless, as IRQ2 has not been in use
> since the PC/AT as back then it was taken by the 8259A cascade
> interrupt to the slave, with the line posiotion in the slot rerouted to
> newly-created IRQ9. No device could thus make use of this line with
> the pair of 8259A chips. Now in theory INTIN2 of the I/O APIC may be
> usable, but the interrupt of the device wired to it would not be
> available in the PIC mode at all, so I seriously doubt if anybody
> decided to reuse it for a regular device (anybody please feel free to
> prove me otherwise).
>
> However there are two common uses of INTIN2. One is for IRQ0, with an
> ACPI interrupt override (or its equivalent in the MP table). But in
> this case IRQ2 is gone entirely with INTIN0 left vacant. The other one
> is for an 8959A ExtINTA cascade. In this case IRQ0 goes to INTIN0 and
> if ACPI is used INTIN2 is assumed to be IRQ2 (there is no override and
> ACPI has no way to report ExtINTA interrupts). This is where a problem
> happens.
>
> The problem is INTIN2 is configured as a native APIC interrupt, with a
> vector assigned and the mask cleared. And the line may indeed get
> active and inject interrupts if the master 8959A has its timer
> interrupt enabled (it might happen for other interrupts too, but they
> are normally masked in the process of rerouting them to the I/O APIC).
> There are two cases where it will happen:
>
> * When the I/O APIC NMI watchdog is enabled. This is actually a
> misnomer as the watchdog pulses are delivered through the 8259A to
> the LINT0 inputs of all the local APICs in the system. The
> implication is the output of the master 8259A goes high and low
> repeatedly, signalling interrupts to INTIN2 which is enabled too!
>
> [The origin of the name is I think for a brief period during the
> development we had a capability in our code to configure the watchdog
> to use an I/O APIC input; that would be INTIN2 in this scenario.]
>
> * When the native route of IRQ0 via INTIN0 fails for whatever reason --
> as it happens with the system considered here. In this scenario the
> timer pulse is delivered through the 8259A to LINT0 input of the
> local APIC of the bootstrap processor, quite similarly to how is done
> for the watchdog described above. The result is, again, INTIN2
> receives these pulses too. Rafael's system used to escape this
> scenario, because an incorrect IRQ0 override would occupy INTIN2 and
> prevent it from being unmasked.
>
> My conclusion is IRQ2 should be excluded from configuration in all the
> cases and the current exception for ACPI systems should be lifted. The
> reason being the exception not only being useless, but harmful as well.
Before I reread all the above -- here are just some early comments
regarding the IRQ0 override:
* HPET timer 0 in legacy mode should be connected to INTIN2.
* To configure this at least some chipsets are able to "swap" INTIN0
and INTIN2:
Say default is IRQ0 -> INTIN0 and output of PIC -> INTIN2. Doing
"some chipset magic" it is possible to swap it such that IRQ0 ->
INTIN2 and output of PIC -> INTIN0.
I might be wrong but maybe that "feature" was invented for HPET
usage in legacy mode -- to deliver timer interrupts to INTIN2.
IMHO for this scenario the IRQ0/INTIN2 override exists.
To complete the confusion, the nx6325 box that I am testing on
advertises an IRQ0/INTIN2 override but INTIN0/INTIN2 are _not_
swapped ... That's the point where I think the BIOS of the box is
totally broken or I just missed some real important bit. ;-(
Regards,
Andreas
On Thu, 10 Jul 2008, Andreas Herrmann wrote:
> FYI, I looked further into the missing interrupt problem (testing on
> 64-bit, with Rafael's patch version and "Virtual Wire Mode" for the
> timer IRQ).
> Just before the weird behaviour I have two log entries:
>
> APIC error on CPU1: 00(40)
> APIC error on CPU0: 00(40)
>
> AFAIK 0x40 is "Illegal Register Address" error:
>
> "Illegal Register Address (IRA)Bit 7. The IRA bit when set to 1
> indicates that an access to an unimplemented register location within
> the local APIC register range (APIC Base Address + 4 Kbytes) was
> attempted."
>
> I've tried to track down who is responsible for that access. But I
> didn't find the offender yet. Maybe it's Linux or some SMM stuff?
> Don't know.
>
> Right after those messages no interrupts from PIT/PIC (which should be
> "virtual wired" to LVT0 of CPU0) are received anymore. I dumped PIC
> and local APIC settings but I did not find any suspicious things here.
The return address from the interrupt handler would be useful here as I
would expect it not to be far off from the offending access. I haven't
seen such errors on my system, so I cannot track the cause down myself.
> Before I reread all the above -- here are just some early comments
> regarding the IRQ0 override:
>
> * HPET timer 0 in legacy mode should be connected to INTIN2.
The HPET spec uses INTIN2 throughout, but I think unless a counterexample
is seen, we should simply assume it uses the same lines the 8254 uses or
would use, which is ISA IRQ0, and is subject to the same ACPI interrupt
routing rules. This is especially implied by how the LEG_RT_CNF bit has
been specified and what common sense suggests. Alternatively we could
assume any system which maps ISA IRQ0 to INTIN0 is not compliant to the
HPET spec.
I cannot tell more about the HPET in the native mode at the moment --
certainly it is not safe to share an I/O APIC pin between an HPET
interrupt and the ExtINTA line. And ACPI has no way to report ExtINTA
lines, so I suppose the best bet is either to reuse the line that is known
to work for IRQ0, replacing the 8254 or to avoid the legacy range of up to
IRQ15 in the APIC mode altogether. All I can say is the three HPET timers
on my system support the interrupts IRQ20-23 as well as, in the case of
the timer #2, IRQ11.
Unfortunately the quality of the spec (at least version 1.0a I have here)
is rather substandard.
> * To configure this at least some chipsets are able to "swap" INTIN0
> and INTIN2:
>
> Say default is IRQ0 -> INTIN0 and output of PIC -> INTIN2. Doing
> "some chipset magic" it is possible to swap it such that IRQ0 ->
> INTIN2 and output of PIC -> INTIN0.
>
> I might be wrong but maybe that "feature" was invented for HPET
> usage in legacy mode -- to deliver timer interrupts to INTIN2.
> IMHO for this scenario the IRQ0/INTIN2 override exists.
Well, it sounds like a "feature" to workaround the broken spec which
refers explicitly to INTIN2 rather than ISA IRQ0. Historically, IRQ0 was
typically routed to INTIN2 rather than INTIN0 (and the ExtINTA line went
to the latter) even on APIC implementations as discrete as the 82489DX,
where the system implementer had full freedom to route lines however they
liked as all were external and went through the PCB.
The only explanation I could imagine is such a setup was specified among
the few "default configurations" Intel's Multiprocessor Specification
provided. Even in its first publicly available version 1.1 full routing
tables could have been specified which could describe arbitrary
configurations. However it is possible earlier versions might have been
limited in this regard and for example provide for these "default
configurations" only. I have a vague recollection from some discussion
which makes me think this was really the case. Then most of the
implementers followed the early ones, including interrupt routing
hardwired on-chip inside more integrated implementations, and therefore
most of the systems at least up to the moment ACPI has started being
deployed used the arrangement where IRQ0 is wired to INTIN2.
> To complete the confusion, the nx6325 box that I am testing on
> advertises an IRQ0/INTIN2 override but INTIN0/INTIN2 are _not_
> swapped ... That's the point where I think the BIOS of the box is
> totally broken or I just missed some real important bit. ;-(
I have posted the patches now -- it has been longer than expected, but
with the number of local patches in my tree reaching 90 I had to improve
procedures for tree updates and it took me some extra time. I think these
patches will let us improve some other code that has been recently
prepared to tackle this nx6325 breakage as soon as possible. I'll have a
look into it.
Now that you mentioned that the SB400 is capable of swapping INTIN0 and
INTIN2, I think this is information we could make use of to patch
interrupt routing tables correctly. Is the state of the swapping circuit
readable from the chip anywhere?
Maciej
On Wed, 9 Jul 2008 09:59:24 +0200 (CEST) Jiri Kosina wrote:
> On Tue, 8 Jul 2008, Randy Dunlap wrote:
>
> > drivers/built-in.o: In function `usb_kbd_probe':
> > usbkbd.c:(.text+0x1457c9): undefined reference to `usbhid_lookup_quirk'
> > drivers/built-in.o: In function `usb_mouse_probe':
> > usbmouse.c:(.text+0x14603c): undefined reference to `usbhid_lookup_quirk'
> > make[1]: *** [.tmp_vmlinux1] Error 1
>
> This got introduced by Jiri's
>
> HID: fix quirk handling in usbmouse/kbd
>
> Added to CC (and added also Pascal).
>
> The dependency of usbkbd/usbmouse on usbhid is strange anyway. I'd
> probably remove the whole quirk lookup thing from usbkbd/usbmouse drivers.
> They introduce this ugly dependency, which is not worth it I guess. Also
> usbkbd/usbmouse drivers are not needed in the vast majority of cases
> anyway, and they shouldn't be loaded in standard configurations at all.
Build error still present in linux-next 20080718.
Please fix it in some manner.
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Fri, 18 Jul 2008, Randy Dunlap wrote:
>> The dependency of usbkbd/usbmouse on usbhid is strange anyway. I'd
>> probably remove the whole quirk lookup thing from usbkbd/usbmouse
>> drivers. They introduce this ugly dependency, which is not worth it I
>> guess. Also usbkbd/usbmouse drivers are not needed in the vast majority
>> of cases anyway, and they shouldn't be loaded in standard
>> configurations at all.
> Build error still present in linux-next 20080718.
> Please fix it in some manner.
OK, I have just completely removed the quirk lookup from usbmouse/usbkbd
drivers. So this should be fixed in next -next.
Thanks,
--
Jiri Kosina
SUSE Labs