* linux-next: Tree for September 3
@ 2008-09-03 9:16 Stephen Rothwell
2008-09-04 2:32 ` [PATCH] hid: fix gyration build error Randy Dunlap
` (2 more replies)
0 siblings, 3 replies; 53+ messages in thread
From: Stephen Rothwell @ 2008-09-03 9:16 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 9867 bytes --]
Hi all,
Changes since next-20080902:
The dwmw2 tree lost its conflict that required a revert.
The x86 tree gained a conflict against the dwmw2 tree.
The block tree gained two conflicts against Linus' tree and the merge
needed a build fix patch. Jens updated the tree, so at the end of the
build, I reverted it and merged the new one.
The ttydev tree gained a trivial conflict against Linus' tree
(unreported) but lost its build fix patch.
I have also applied the following patches for known problems:
ftrace: protect the definition of ftrace_release
revert BUILD_BUG_ON change
Revert "debug: add notifier chain debugging"
debug: add notifier chain debugging (different version)
sparc: qlogicpti fallout from sbus removal
powerpc: make sure all kernel test is before _etext
statfs: fix typo
----------------------------------------------------------------------------
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 113 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 sfr@canb.auug.org.au
$ 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
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 quilt/m68k
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/powerpc-next
Merging 4xx/next
Merging galak/powerpc-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in include/asm-x86/cpufeature.h
CONFLICT (content): Merge conflict in include/asm-x86/statfs.h
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/module.c
Applying ftrace: remove warning of old objcopy and local functions
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
CONFLICT (content): Merge conflict in include/asm-x86/pda.h
CONFLICT (content): Merge conflict in kernel/fork.c
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
CONFLICT (content): Merge conflict in drivers/hid/usbhid/hid-core.c
Applying HID: fix for warn() removal
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/stable
CONFLICT (content): Merge conflict in drivers/media/radio/dsbr100.c
CONFLICT (content): Merge conflict in drivers/media/video/zr364xx.c
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
CONFLICT (content): Merge conflict in drivers/misc/acer-wmi.c
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in include/asm-x86/kvm.h
Merging dlm/next
Merging scsi/master
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
Applying rr: build fix for remove CONFIG_KMOD from net
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
Merging bkl-removal/bkl-removal
Merging trivial/next
CONFLICT (content): Merge conflict in Documentation/edac.txt
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in block/cmd-filter.c
CONFLICT (content): Merge conflict in block/genhd.c
CONFLICT (content): Merge conflict in drivers/ide/ide-disk.c
CONFLICT (content): Merge conflict in drivers/md/dm-mpath.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Applying block: merge fallout in genhd.c
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/scsi/qlogicpti.c
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/kernel/process_64.c
CONFLICT (content): Merge conflict in arch/x86/kernel/traps_64.c
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in 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
Merging drm/drm-next
Merging voltage/reg-for-linus
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in drivers/char/tty_io.c
CONFLICT (content): Merge conflict in drivers/char/vt.c
CONFLICT (content): Merge conflict in drivers/usb/serial/aircable.c
CONFLICT (content): Merge conflict in drivers/usb/serial/keyspan_pda.c
CONFLICT (content): Merge conflict in drivers/usb/serial/safe_serial.c
CONFLICT (content): Merge conflict in kernel/auditsc.c
Merging agp/agp-next
Merging creds/next-creds
CONFLICT (content): Merge conflict in drivers/net/wan/sbni.c
CONFLICT (content): Merge conflict in fs/namespace.c
CONFLICT (content): Merge conflict in fs/nfsd/nfs4recover.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_linux.h
CONFLICT (content): Merge conflict in fs/xfs/xfs_inode.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.c
CONFLICT (content): Merge conflict in include/linux/capability.h
CONFLICT (add/add): Merge conflict in include/linux/cred.h
CONFLICT (content): Merge conflict in include/linux/security.h
CONFLICT (content): Merge conflict in kernel/exit.c
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (content): Merge conflict in security/commoncap.c
CONFLICT (content): Merge conflict in security/selinux/hooks.c
CONFLICT (content): Merge conflict in security/smack/smack_lsm.c
Merging oprofile/auto-oprofile-next
CONFLICT (content): Merge conflict in arch/x86/kernel/apic_32.c
Merging fastboot/auto-fastboot-next
CONFLICT (content): Merge conflict in include/linux/init.h
Merging sparseirq/auto-sparseirq-next
CONFLICT (delete/modify): arch/x86/kernel/apic_64.c deleted in sparseirq/auto-sparseirq-next and modified in HEAD. Version HEAD of arch/x86/kernel/apic_64.c left in tree.
CONFLICT (content): Merge conflict in arch/x86/xen/spinlock.c
CONFLICT (content): Merge conflict in drivers/serial/68328serial.c
CONFLICT (content): Merge conflict in drivers/serial/8250.c
$ git rm arch/x86/kernel/apic_64.c
Applying revert BUILD_BUG_ON change
Applying ftrace: protect the definition of ftrace_release
Created commit bd93170: Revert "debug: add notifier chain debugging"
Applying debug: add notifier chain debugging
Applying sparc: qlogicpti fallout from sbus removal
Applying powerpc: make sure all kernel test is before _etext
Created commit 25a5c8f: Revert "Merge commit 'block/for-next'"
Merging block_tmp
CONFLICT (content): Merge conflict in drivers/ide/ide-disk.c
CONFLICT (content): Merge conflict in drivers/md/dm-mpath.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Applying statfs: fix typo
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH] hid: fix gyration build error
2008-09-03 9:16 linux-next: Tree for September 3 Stephen Rothwell
@ 2008-09-04 2:32 ` Randy Dunlap
2008-09-04 6:52 ` Jiri Slaby
2008-09-04 4:42 ` linux-next: Tree for September 3 Andrew Morton
2008-09-04 4:46 ` Andrew Morton
2 siblings, 1 reply; 53+ messages in thread
From: Randy Dunlap @ 2008-09-04 2:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, jkosina, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix config symbol name in ifdef to fix build error:
ERROR: "hid_compat_gyration" [drivers/hid/hid-dummy.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-dummy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20080903.orig/drivers/hid/hid-dummy.c
+++ linux-next-20080903/drivers/hid/hid-dummy.c
@@ -28,7 +28,7 @@ static int __init hid_dummy_init(void)
#ifdef CONFIG_HID_EZKEY_MODULE
HID_COMPAT_CALL_DRIVER(ezkey);
#endif
-#ifdef CONFIG_HID_EZKEY_MODULE
+#ifdef CONFIG_HID_GYRATION_MODULE
HID_COMPAT_CALL_DRIVER(gyration);
#endif
#ifdef CONFIG_HID_LOGITECH_MODULE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-03 9:16 linux-next: Tree for September 3 Stephen Rothwell
2008-09-04 2:32 ` [PATCH] hid: fix gyration build error Randy Dunlap
@ 2008-09-04 4:42 ` Andrew Morton
2008-09-04 4:46 ` Andrew Morton
2 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 4:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, linux-acpi
On Wed, 3 Sep 2008 19:16:19 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
ug. What a lot of bugs.
acpi:
calling param_sysfs_init+0x0/0x153
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:465 sysfs_add_one+0x2a/0x36()
sysfs: duplicate filename 'acpi' can not be created
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.27-rc5 #4
[<c01208e4>] warn_slowpath+0x4e/0x77
[<c013e30f>] ? __lock_acquire+0x671/0x6b7
[<c013a79e>] ? trace_hardirqs_off+0xb/0xd
[<c0108621>] ? native_sched_clock+0x82/0x96
[<c018a1de>] ? ifind+0x7e/0x88
[<c032fee9>] ? _spin_unlock+0x27/0x3c
[<c018a1de>] ? ifind+0x7e/0x88
[<c01b7262>] ? sysfs_find_dirent+0x16/0x27
[<c01b72fc>] sysfs_add_one+0x2a/0x36
[<c01b779d>] create_dir+0x43/0x71
[<c01b77f8>] sysfs_create_dir+0x2d/0x41
[<c032fee9>] ? _spin_unlock+0x27/0x3c
[<c01fa600>] kobject_add_internal+0xb3/0x157
[<c01fa74f>] kobject_add_varg+0x35/0x41
[<c01fa8cd>] kobject_init_and_add+0x26/0x28
[<c049160c>] kernel_param_sysfs_setup+0x4c/0x99
[<c0491750>] param_sysfs_init+0xf7/0x153
[<c0101125>] _stext+0x3d/0x11d
[<c0491659>] ? param_sysfs_init+0x0/0x153
[<c011c8af>] ? wake_up_process+0xf/0x11
[<c012d8b9>] ? start_workqueue_thread+0x1d/0x20
[<c012de97>] ? __create_workqueue_key+0xe4/0xfc
[<c0482767>] kernel_init+0xeb/0x152
[<c048267c>] ? kernel_init+0x0/0x152
[<c01046ef>] kernel_thread_helper+0x7/0x10
=======================
---[ end trace 4eaa2a86a8e2da22 ]---
kobject_add_internal failed for acpi with -EEXIST, don't try to register things with the same name in the same directory.
Pid: 1, comm: swapper Tainted: G W 2.6.27-rc5 #4
[<c01fa66c>] kobject_add_internal+0x11f/0x157
[<c01fa74f>] kobject_add_varg+0x35/0x41
[<c01fa8cd>] kobject_init_and_add+0x26/0x28
[<c049160c>] kernel_param_sysfs_setup+0x4c/0x99
[<c0491750>] param_sysfs_init+0xf7/0x153
[<c0101125>] _stext+0x3d/0x11d
[<c0491659>] ? param_sysfs_init+0x0/0x153
[<c011c8af>] ? wake_up_process+0xf/0x11
[<c012d8b9>] ? start_workqueue_thread+0x1d/0x20
[<c012de97>] ? __create_workqueue_key+0xe4/0xfc
[<c0482767>] kernel_init+0xeb/0x152
[<c048267c>] ? kernel_init+0x0/0x152
[<c01046ef>] kernel_thread_helper+0x7/0x10
=======================
Module 'acpi' failed to be added to sysfs, error number -17
there seem to have been tens or even hunderds of reports of this. Odd.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-03 9:16 linux-next: Tree for September 3 Stephen Rothwell
2008-09-04 2:32 ` [PATCH] hid: fix gyration build error Randy Dunlap
2008-09-04 4:42 ` linux-next: Tree for September 3 Andrew Morton
@ 2008-09-04 4:46 ` Andrew Morton
2008-09-04 4:54 ` Andrew Morton
2008-09-04 5:21 ` Linus Torvalds
2 siblings, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 4:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds
On Wed, 3 Sep 2008 19:16:19 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
The Vaio says:
calling init_acpi_pm_clocksource+0x0/0x14a
initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
calling pcibios_assign_resources+0x0/0x70
pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
pci 0000:06:05.0: IO window: 0x002400-0x0024ff
pci 0000:06:05.0: IO window: 0x002800-0x0028ff
pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
pci 0000:00:1e.0: IO window: 0x2000-0x2fff
pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
pci 0000:00:1e.0: PREFETCH window: disabled
pci 0000:00:1e.0: setting latency timer to 64
pci 0000:06:05.0: power state changed by ACPI to D0
found new irq_cfg for irq 21
0 add_pin_to_irq: irq 21 --> apic 0 pin 21
found new irq_desc for irq 21
pci 0000:06:05.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
Should I worry?
sony:/home/akpm> cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:1f.1
0170-0177 : ata_piix
01f0-01f7 : 0000:00:1f.1
01f0-01f7 : ata_piix
0376-0376 : 0000:00:1f.1
0376-0376 : ata_piix
03c0-03df : vesafb
03f6-03f6 : 0000:00:1f.1
03f6-03f6 : ata_piix
0680-068f : pnp 00:05
0800-080f : pnp 00:05
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
1000-107f : pnp 00:05
1000-1003 : ACPI PM1a_EVT_BLK
1004-1005 : ACPI PM1a_CNT_BLK
1008-100b : ACPI PM_TMR
1010-1015 : ACPI CPU throttle
1020-1020 : ACPI PM2_CNT_BLK
1028-102f : ACPI GPE0_BLK
1080-109f : Sony Programable I/O Device
1180-11bf : 0000:00:1f.0
1180-11bf : pnp 00:05
1800-1807 : 0000:00:02.0
180c-180f : 0000:00:1f.2
180c-180f : ata_piix
1810-181f : 0000:00:1f.1
1810-181f : ata_piix
1820-183f : 0000:00:1d.0
1820-183f : uhci_hcd
1840-185f : 0000:00:1d.1
1840-185f : uhci_hcd
1860-187f : 0000:00:1d.2
1860-187f : uhci_hcd
1880-189f : 0000:00:1d.3
1880-189f : uhci_hcd
18a8-18af : 0000:00:1f.2
18a8-18af : ata_piix
18b0-18bf : 0000:00:1f.2
18b0-18bf : ata_piix
18c0-18c3 : 0000:00:1f.2
18c0-18c3 : ata_piix
18c8-18cf : 0000:00:1f.2
18c8-18cf : ata_piix
18e0-18ff : 0000:00:1f.3
18e0-18ff : i801_smbus
2000-2fff : PCI Bus 0000:06
2000-203f : 0000:06:08.0
2000-203f : e100
2400-24ff : PCI CardBus 0000:07
2800-28ff : PCI CardBus 0000:07
fe00-fe01 : pnp 00:05
sony:/home/akpm> cat /proc/iomem
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000d8000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-3f68ffff : System RAM
00100000-00330fd9 : Kernel code
00330fda-0047fe7f : Kernel data
004bc000-00ad7b13 : Kernel bss
3f690000-3f69cfff : ACPI Tables
3f69d000-3f6fffff : ACPI Non-volatile Storage
3f700000-3fffffff : reserved
50000000-5007ffff : 0000:00:02.1
50080000-50080fff : Intel Flush Page
50400000-507fffff : PCI CardBus 0000:07
54000000-57ffffff : PCI CardBus 0000:07
b0000000-b0003fff : 0000:00:1b.0
b0000000-b0003fff : ICH HD audio
b0004000-b00043ff : 0000:00:1d.7
b0004000-b00043ff : ehci_hcd
b0004400-b00047ff : 0000:00:1f.2
b0040000-b007ffff : 0000:00:02.0
b0080000-b00fffff : 0000:00:02.0
b0100000-b01fffff : PCI Bus 0000:06
b0100000-b0103fff : 0000:06:05.2
b0104000-b01047ff : 0000:06:05.2
b0104000-b01047ff : ohci1394
b0105000-b0105fff : 0000:06:05.3
b0106000-b0106fff : 0000:06:08.0
b0106000-b0106fff : e100
b0107000-b0107fff : 0000:06:0b.0
b0107000-b0107fff : ipw2200
b0108000-b0108fff : 0000:06:05.0
b0108000-b0108fff : yenta_socket
c0000000-cfffffff : 0000:00:02.0
c0000000-c07affff : vesafb
d000c000-d000ffff : pnp 00:05
e0000000-f0005fff : reserved
e0000000-efffffff : PCI MMCONFIG 0
f0008000-f000bfff : reserved
fec00000-fec00fff : IOAPIC 0
fed20000-fed8ffff : reserved
fee00000-fee00fff : Local APIC
ff000000-ffffffff : reserved
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
config: http://userweb.kernel.org/~akpm/config-sony.txt
There are no immediately-obvious problems. Apart from the lack of any
login prompt on the console (sshd works), but I suspect that was a
separate gift.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 4:46 ` Andrew Morton
@ 2008-09-04 4:54 ` Andrew Morton
2008-09-04 4:57 ` Stephen Rothwell
2008-09-04 5:00 ` Stephen Rothwell
2008-09-04 5:21 ` Linus Torvalds
1 sibling, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 4:54 UTC (permalink / raw)
To: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Linus Torvalds
On Wed, 3 Sep 2008 21:46:34 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> Apart from the lack of any
> login prompt on the console (sshd works), but I suspect that was a
> separate gift.
And the very first damn bisection point goes:
In file included from include/asm/statfs.h:11,
from include/linux/statfs.h:6,
from include/linux/vfs.h:4,
from fs/open.c:22:
include/asm-generic/statfs.h:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__u32'
and that bisection breakage is going to get trotted into mainline
for evermore.
Great.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 4:54 ` Andrew Morton
@ 2008-09-04 4:57 ` Stephen Rothwell
2008-09-04 5:05 ` Andrew Morton
2008-09-04 5:00 ` Stephen Rothwell
1 sibling, 1 reply; 53+ messages in thread
From: Stephen Rothwell @ 2008-09-04 4:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
Hi Andrew,
On Wed, 3 Sep 2008 21:54:55 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 3 Sep 2008 21:46:34 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > Apart from the lack of any
> > login prompt on the console (sshd works), but I suspect that was a
> > separate gift.
>
> And the very first damn bisection point goes:
>
> In file included from include/asm/statfs.h:11,
> from include/linux/statfs.h:6,
> from include/linux/vfs.h:4,
> from fs/open.c:22:
> include/asm-generic/statfs.h:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__u32'
>
> and that bisection breakage is going to get trotted into mainline
> for evermore.
No it isn't because it came from dwmw2's tree and that has already been
rewritten/rebased ...
--
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 [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 4:54 ` Andrew Morton
2008-09-04 4:57 ` Stephen Rothwell
@ 2008-09-04 5:00 ` Stephen Rothwell
1 sibling, 0 replies; 53+ messages in thread
From: Stephen Rothwell @ 2008-09-04 5:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Hi Andrew,
On Wed, 3 Sep 2008 21:54:55 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 3 Sep 2008 21:46:34 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > Apart from the lack of any
> > login prompt on the console (sshd works), but I suspect that was a
> > separate gift.
>
> And the very first damn bisection point goes:
>
> In file included from include/asm/statfs.h:11,
> from include/linux/statfs.h:6,
> from include/linux/vfs.h:4,
> from fs/open.c:22:
> include/asm-generic/statfs.h:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__u32'
for a short term fix, apply the "statfs: fix typo" commit from right near
the end of next-20080903.
--
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 [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 4:57 ` Stephen Rothwell
@ 2008-09-04 5:05 ` Andrew Morton
2008-09-04 5:20 ` Stephen Rothwell
2008-09-04 5:26 ` Linus Torvalds
0 siblings, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 5:05 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds
On Thu, 4 Sep 2008 14:57:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> On Wed, 3 Sep 2008 21:54:55 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Wed, 3 Sep 2008 21:46:34 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > Apart from the lack of any
> > > login prompt on the console (sshd works), but I suspect that was a
> > > separate gift.
> >
> > And the very first damn bisection point goes:
> >
> > In file included from include/asm/statfs.h:11,
> > from include/linux/statfs.h:6,
> > from include/linux/vfs.h:4,
> > from fs/open.c:22:
> > include/asm-generic/statfs.h:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__u32'
> >
> > and that bisection breakage is going to get trotted into mainline
> > for evermore.
>
> No it isn't because it came from dwmw2's tree and that has already been
> rewritten/rebased ...
Thank gawd for that.
This breakage spans over 1000 commits. Not sure how that can happen in
a rebased tree, but whatever.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:05 ` Andrew Morton
@ 2008-09-04 5:20 ` Stephen Rothwell
2008-09-04 6:01 ` Andrew Morton
2008-09-04 5:26 ` Linus Torvalds
1 sibling, 1 reply; 53+ messages in thread
From: Stephen Rothwell @ 2008-09-04 5:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
Hi Andrew,
On Wed, 3 Sep 2008 22:05:46 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Thank gawd for that.
>
> This breakage spans over 1000 commits. Not sure how that can happen in
> a rebased tree, but whatever.
It happens because I merge that tree into linux-next early in the
sequence and the two builds I do after each merge did not get the error
(*and* David really did not do enough testing ...). The set of builds I
do after merging all the trees hit that so I added a commit to the end of
linux-next to fix it.
That particular build bug will not be in today's linux-next because that
particular tree has been fixed.
--
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 [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 4:46 ` Andrew Morton
2008-09-04 4:54 ` Andrew Morton
@ 2008-09-04 5:21 ` Linus Torvalds
2008-09-04 5:33 ` Andrew Morton
1 sibling, 1 reply; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 5:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu
On Wed, 3 Sep 2008, Andrew Morton wrote:
>
> The Vaio says:
>
> calling init_acpi_pm_clocksource+0x0/0x14a
> initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> calling pcibios_assign_resources+0x0/0x70
> pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
Hmm. This should not be a new warning, afaik.
But it looks totally bogus.
The code does:
r_size = r->end - r->start + 1;
/* For bridges size != alignment */
align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
order = __ffs(align) - 20;
if (order > 11) {
dev_warn(&dev->dev, "BAR %d too large: "
"%#016llx-%#016llx\n", i,
(unsigned long long)r->start,
(unsigned long long)r->end);
and the thing is, that's a bridge resource, so it chooses r_start as the
alignment. Which is zero. so now __ffs(align) returns a bogus value, and
you get the bogus warning.
But CARDBUS bridges are _different_ from normal PCI bridges, and the
alignment value isn't r->start. Strictly speaking it's not r_size either,
it's always a fixed alignment of 4096 for MMIO bridging, i think. Maybe.
Whatever. But our resource handling code can't handle that, and always
wants either size alignment or start alignment.
But for cardbus bridges, we should be doing size alignment, and the
problem is that that code doesn't do the proper "resource_alignment()"
use.
Can you apply this patch, just to see if it fixes things.
And do you know when this started happening? It shouldn't have been all
that recent. Maybe you haven't tried your Vaio in a while?
Linus
---
drivers/pci/setup-bus.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 82634a2..1aad599 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -352,11 +352,12 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, unsigned long
continue;
r_size = r->end - r->start + 1;
/* For bridges size != alignment */
- align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
+ align = resource_alignment(r);
order = __ffs(align) - 20;
if (order > 11) {
- dev_warn(&dev->dev, "BAR %d too large: "
+ dev_warn(&dev->dev, "BAR %d bad alignment %llx: "
"%#016llx-%#016llx\n", i,
+ (unsigned long long)align,
(unsigned long long)r->start,
(unsigned long long)r->end);
r->flags = 0;
^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:05 ` Andrew Morton
2008-09-04 5:20 ` Stephen Rothwell
@ 2008-09-04 5:26 ` Linus Torvalds
2008-09-04 5:42 ` Andrew Morton
1 sibling, 1 reply; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 5:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu
On Wed, 3 Sep 2008, Andrew Morton wrote:
>
> This breakage spans over 1000 commits. Not sure how that can happen in
> a rebased tree, but whatever.
If the only problem is that dmesg thing, and that cardbus doesn't work as
a result, try my small patch before even bothering to bisect. I _think_ it
will fix that thing.
But that particular thing actually comes from my source tree and is not
linux-next specific, so if this is something that started happening only
with Linux-next, and doesn't happen in my tree, then there is something
else going on too with your Vaio.
Maybe that cardbus problem has been going on for a while, and you just
didn't notice because it didn't matter? And now you have some new problem
that is unrelated to that resource thing?
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:21 ` Linus Torvalds
@ 2008-09-04 5:33 ` Andrew Morton
2008-09-04 7:14 ` Yinghai Lu
2008-09-04 8:02 ` Linus Torvalds
0 siblings, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 5:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu
On Wed, 3 Sep 2008 22:21:54 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Sep 2008, Andrew Morton wrote:
> >
> > The Vaio says:
> >
> > calling init_acpi_pm_clocksource+0x0/0x14a
> > initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> > calling pcibios_assign_resources+0x0/0x70
> > pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
>
> Hmm. This should not be a new warning, afaik.
>
> But it looks totally bogus.
>
> The code does:
>
> r_size = r->end - r->start + 1;
> /* For bridges size != alignment */
> align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
> order = __ffs(align) - 20;
> if (order > 11) {
> dev_warn(&dev->dev, "BAR %d too large: "
> "%#016llx-%#016llx\n", i,
> (unsigned long long)r->start,
> (unsigned long long)r->end);
>
> and the thing is, that's a bridge resource, so it chooses r_start as the
> alignment. Which is zero. so now __ffs(align) returns a bogus value, and
> you get the bogus warning.
>
> But CARDBUS bridges are _different_ from normal PCI bridges, and the
> alignment value isn't r->start. Strictly speaking it's not r_size either,
> it's always a fixed alignment of 4096 for MMIO bridging, i think. Maybe.
> Whatever. But our resource handling code can't handle that, and always
> wants either size alignment or start alignment.
>
> But for cardbus bridges, we should be doing size alignment, and the
> problem is that that code doesn't do the proper "resource_alignment()"
> use.
>
> Can you apply this patch, just to see if it fixes things.
Below..
> And do you know when this started happening? It shouldn't have been all
> that recent. Maybe you haven't tried your Vaio in a while?
Yes, the Vaio had a vacation in New York. Last kernel it booted was
2.6.26-rc8-mm1.
--- x 2008-09-03 21:38:24.000000000 -0700
+++ y 2008-09-03 22:29:04.000000000 -0700
...
@@ -503,15 +503,15 @@
calling init_acpi_pm_clocksource+0x0/0x14a
initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
calling pcibios_assign_resources+0x0/0x70
-pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
pci 0000:06:05.0: IO window: 0x002400-0x0024ff
pci 0000:06:05.0: IO window: 0x002800-0x0028ff
-pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
+pci 0000:06:05.0: PREFETCH window: 0x50000000-0x53ffffff
+pci 0000:06:05.0: MEM window: 0x58000000-0x5bffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
pci 0000:00:1e.0: IO window: 0x2000-0x2fff
pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
-pci 0000:00:1e.0: PREFETCH window: disabled
+pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x00000053ffffff
pci 0000:00:1e.0: setting latency timer to 64
pci 0000:06:05.0: power state changed by ACPI to D0
found new irq_cfg for irq 21
@@ -522,13 +522,13 @@
bus: 00 index 1 mmio: [0, ffffffff]
bus: 06 index 0 io port: [2000, 2fff]
bus: 06 index 1 mmio: [b0100000, b01fffff]
-bus: 06 index 2 mmio: [0, 0]
+bus: 06 index 2 mmio: [50000000, 53ffffff]
bus: 06 index 3 io port: [0, ffff]
bus: 06 index 4 mmio: [0, ffffffff]
bus: 07 index 0 io port: [2400, 24ff]
bus: 07 index 1 io port: [2800, 28ff]
-bus: 07 index 2 mmio: [0, 3ffffff]
-bus: 07 index 3 mmio: [54000000, 57ffffff]
+bus: 07 index 2 mmio: [50000000, 53ffffff]
+bus: 07 index 3 mmio: [58000000, 5bffffff]
initcall pcibios_assign_resources+0x0/0x70 returned 0 after 0 msecs
calling inet_init+0x0/0x1c3
NET: Registered protocol family 2
also...
@@ -860,16 +860,11 @@
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 < sda5 sda6 >
sd 2:0:0:0: [sda] Attached SCSI disk
-initcall piix_init+0x0/0x27 returned 0 after 1128 msecs
+initcall piix_init+0x0/0x27 returned 0 after 1136 msecs
calling nonstatic_sysfs_init+0x0/0xf
initcall nonstatic_sysfs_init+0x0/0xf returned 0 after 0 msecs
calling yenta_socket_init+0x0/0x16
yenta_cardbus 0000:06:05.0: CardBus bridge found [104d:818f]
-yenta_cardbus 0000:06:05.0: CardBus bridge, secondary bus 0000:07
-yenta_cardbus 0000:06:05.0: IO window: 0x002400-0x0024ff
-yenta_cardbus 0000:06:05.0: IO window: 0x002800-0x0028ff
-yenta_cardbus 0000:06:05.0: PREFETCH window: 0x50400000-0x507fffff
-yenta_cardbus 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
yenta_cardbus 0000:06:05.0: Using CSCINT to route CSC interrupts to PCI
yenta_cardbus 0000:06:05.0: Routing CardBus interrupts to PCI
yenta_cardbus 0000:06:05.0: TI: mfunc 0x01001b22, devctl 0x64
@@ -878,7 +873,8 @@
pci_bus 0000:06: Raising subordinate bus# of parent bus (#06) from #07 to #0a
yenta_cardbus 0000:06:05.0: pcmcia: parent PCI bridge I/O window: 0x2000 - 0x2fff
yenta_cardbus 0000:06:05.0: pcmcia: parent PCI bridge Memory window: 0xb0100000 - 0xb01fffff
-initcall yenta_socket_init+0x0/0x16 returned 0 after 499 msecs
+yenta_cardbus 0000:06:05.0: pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x53ffffff
+initcall yenta_socket_init+0x0/0x16 returned 0 after 492 msecs
calling mon_init+0x0/0xee
initcall mon_init+0x0/0xee returned 0 after 0 msecs
calling i8042_init+0x0/0x357
Full dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-2.txt
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:26 ` Linus Torvalds
@ 2008-09-04 5:42 ` Andrew Morton
0 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 5:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu
On Wed, 3 Sep 2008 22:26:23 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Sep 2008, Andrew Morton wrote:
> >
> > This breakage spans over 1000 commits. Not sure how that can happen in
> > a rebased tree, but whatever.
>
> If the only problem is that dmesg thing, and that cardbus doesn't work as
> a result, try my small patch before even bothering to bisect. I _think_ it
> will fix that thing.
>
> But that particular thing actually comes from my source tree and is not
> linux-next specific, so if this is something that started happening only
> with Linux-next, and doesn't happen in my tree, then there is something
> else going on too with your Vaio.
>
> Maybe that cardbus problem has been going on for a while, and you just
> didn't notice because it didn't matter? And now you have some new problem
> that is unrelated to that resource thing?
>
yup, I have a bunch of things going wrong here. The cardbus problem
has no observed-by-me consequences.
I moved on from that and am presently working out why I have no logins
running on the VTs.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:20 ` Stephen Rothwell
@ 2008-09-04 6:01 ` Andrew Morton
2008-09-04 7:15 ` Andrew Morton
0 siblings, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds, David Woodhouse
On Thu, 4 Sep 2008 15:20:15 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> On Wed, 3 Sep 2008 22:05:46 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > Thank gawd for that.
> >
> > This breakage spans over 1000 commits. Not sure how that can happen in
> > a rebased tree, but whatever.
>
> It happens because I merge that tree into linux-next early in the
> sequence and the two builds I do after each merge did not get the error
> (*and* David really did not do enough testing ...). The set of builds I
> do after merging all the trees hit that so I added a commit to the end of
> linux-next to fix it.
>
> That particular build bug will not be in today's linux-next because that
> particular tree has been fixed.
>
After fix-odd iterations:
netconsole: remote IP 192.168.2.111
netconsole: remote ethernet address 00:19:d1:04:8f:42
netconsole: device eth0 not up yet, forcing it
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
Clocksource tsc unstable (delta = -499885471 ns)
console [netcon0] enabled
NETDEV WATCHDOG: eth0 (e100): transmit timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:221 dev_watchdog+0x11c/0x192()
Modules linked in:
Pid: 1, comm: swapper Tainted: G W 2.6.27-rc5 #7
[<c011e67e>] warn_on_slowpath+0x41/0x65
[<c01387f9>] ? print_lock_contention_bug+0x11/0xb2
[<c0119138>] ? __wake_up+0x31/0x3b
[<c013805a>] ? trace_hardirqs_off+0xb/0xd
[<c0326762>] ? _spin_unlock_irqrestore+0x54/0x58
[<c0119138>] ? __wake_up+0x31/0x3b
[<c012ba7a>] ? __queue_work+0x26/0x2b
[<c013a9cd>] ? trace_hardirqs_on+0xb/0xd
[<c0326762>] ? _spin_unlock_irqrestore+0x54/0x58
[<c012ba7a>] ? __queue_work+0x26/0x2b
[<c012bb92>] ? queue_work_on+0x27/0x31
[<c012bc55>] ? queue_work+0x3f/0x45
[<c012bc6a>] ? schedule_work+0xf/0x11
[<c02660e0>] ? e100_tx_timeout+0xd/0xf
[<c02d2ee2>] dev_watchdog+0x11c/0x192
[<c01387f9>] ? print_lock_contention_bug+0x11/0xb2
[<c0125920>] ? run_timer_softirq+0x102/0x16c
[<c013a9cd>] ? trace_hardirqs_on+0xb/0xd
[<c012592f>] run_timer_softirq+0x111/0x16c
[<c02d2dc6>] ? dev_watchdog+0x0/0x192
[<c02d2dc6>] ? dev_watchdog+0x0/0x192
[<c012240a>] __do_softirq+0x51/0xa8
[<c0122490>] do_softirq+0x2f/0x47
[<c0122712>] irq_exit+0x3b/0x79
[<c01115f2>] smp_apic_timer_interrupt+0x63/0x6e
[<c01043dd>] apic_timer_interrupt+0x2d/0x34
[<c011eb90>] ? release_console_sem+0x16e/0x1ab
[<c011eb94>] ? release_console_sem+0x172/0x1ab
[<c011f35b>] register_console+0x20e/0x216
[<c0493587>] init_netconsole+0x12f/0x185
[<c0101125>] _stext+0x3d/0x11d
[<c0493458>] ? init_netconsole+0x0/0x185
[<c01a98ca>] ? create_proc_entry+0x6c/0x80
[<c0153692>] ? register_irq_proc+0x74/0x8d
[<c047a6e2>] kernel_init+0x66/0xb4
[<c047a67c>] ? kernel_init+0x0/0xb4
[<c010456f>] kernel_thread_helper+0x7/0x10
=======================
---[ end trace 4eaa2a86a8e2da22 ]---
netconsole: network logging started
initcall init_netconsole+0x0/0x185 returned 0 after 5916 msecs
calling init_sd+0x0/0xdf
and it's dead.
This is extremely irritating. I'll see if I cen reproduce the bug I'm
actually tring to find with E100=n.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH] hid: fix gyration build error
2008-09-04 2:32 ` [PATCH] hid: fix gyration build error Randy Dunlap
@ 2008-09-04 6:52 ` Jiri Slaby
2008-09-04 8:06 ` Jiri Kosina
0 siblings, 1 reply; 53+ messages in thread
From: Jiri Slaby @ 2008-09-04 6:52 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, jkosina, akpm
On 09/04/2008 04:32 AM, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix config symbol name in ifdef to fix build error:
>
> ERROR: "hid_compat_gyration" [drivers/hid/hid-dummy.ko] undefined!
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> cc: Jiri Kosina <jkosina@suse.cz>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Thanks for catching this. My cut&paste typo.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:33 ` Andrew Morton
@ 2008-09-04 7:14 ` Yinghai Lu
2008-09-04 8:00 ` Andrew Morton
2008-09-04 8:23 ` Linus Torvalds
2008-09-04 8:02 ` Linus Torvalds
1 sibling, 2 replies; 53+ messages in thread
From: Yinghai Lu @ 2008-09-04 7:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Stephen Rothwell, linux-next, LKML
[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]
On Wed, Sep 3, 2008 at 10:33 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 3 Sep 2008 22:21:54 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>>
>>
>> On Wed, 3 Sep 2008, Andrew Morton wrote:
>> >
>> > The Vaio says:
>> >
>> > calling init_acpi_pm_clocksource+0x0/0x14a
>> > initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
>> > calling pcibios_assign_resources+0x0/0x70
>> > pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
>>
>> Hmm. This should not be a new warning, afaik.
>>
>> But it looks totally bogus.
>>
>> The code does:
>>
>> r_size = r->end - r->start + 1;
>> /* For bridges size != alignment */
>> align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
>> order = __ffs(align) - 20;
>> if (order > 11) {
>> dev_warn(&dev->dev, "BAR %d too large: "
>> "%#016llx-%#016llx\n", i,
>> (unsigned long long)r->start,
>> (unsigned long long)r->end);
>>
>> and the thing is, that's a bridge resource, so it chooses r_start as the
>> alignment. Which is zero. so now __ffs(align) returns a bogus value, and
>> you get the bogus warning.
>>
>> But CARDBUS bridges are _different_ from normal PCI bridges, and the
>> alignment value isn't r->start. Strictly speaking it's not r_size either,
>> it's always a fixed alignment of 4096 for MMIO bridging, i think. Maybe.
>> Whatever. But our resource handling code can't handle that, and always
>> wants either size alignment or start alignment.
>>
>> But for cardbus bridges, we should be doing size alignment, and the
>> problem is that that code doesn't do the proper "resource_alignment()"
>> use.
>>
>> Can you apply this patch, just to see if it fixes things.
>
> Below..
>
>> And do you know when this started happening? It shouldn't have been all
>> that recent. Maybe you haven't tried your Vaio in a while?
>
> Yes, the Vaio had a vacation in New York. Last kernel it booted was
> 2.6.26-rc8-mm1.
>
> --- x 2008-09-03 21:38:24.000000000 -0700
> +++ y 2008-09-03 22:29:04.000000000 -0700
> ...
> @@ -503,15 +503,15 @@
> calling init_acpi_pm_clocksource+0x0/0x14a
> initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> calling pcibios_assign_resources+0x0/0x70
> -pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
> pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> pci 0000:06:05.0: IO window: 0x002400-0x0024ff
> pci 0000:06:05.0: IO window: 0x002800-0x0028ff
> -pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
> +pci 0000:06:05.0: PREFETCH window: 0x50000000-0x53ffffff
> +pci 0000:06:05.0: MEM window: 0x58000000-0x5bffffff
> pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
> pci 0000:00:1e.0: IO window: 0x2000-0x2fff
> pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
> -pci 0000:00:1e.0: PREFETCH window: disabled
> +pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x00000053ffffff
> pci 0000:00:1e.0: setting latency timer to 64
> pci 0000:06:05.0: power state changed by ACPI to D0
06:05.0 is under 00:1e.0
wonder if some pci code change cause that.... doesn't get pref mem assigned.
can you apply attached patches to get more dump?
YH
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pci_res_print_out.patch --]
[-- Type: text/x-patch; name=pci_res_print_out.patch, Size: 2471 bytes --]
From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] pci: fix merging left out for BAR print out
print out for Device BAR address before kernel try to update them.
also change it to KERN_DEBUG instead...
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
drivers/pci/probe.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/pci/probe.c
===================================================================
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -304,6 +304,8 @@ static int __pci_read_base(struct pci_de
} else {
res->start = l64;
res->end = l64 + sz64;
+ printk(KERN_DEBUG "PCI: %s reg %x 64bit mmio: [%llx, %llx]\n",
+ pci_name(dev), pos, res->start, res->end);
}
} else {
sz = pci_size(l, sz, mask);
@@ -313,6 +315,10 @@ static int __pci_read_base(struct pci_de
res->start = l;
res->end = l + sz;
+ printk(KERN_DEBUG "PCI: %s reg %x %s: [%llx, %llx]\n", pci_name(dev),
+ pos, (res->flags & IORESOURCE_IO) ? "io port":"32bit mmio",
+ res->start, res->end);
+
}
out:
@@ -383,7 +389,8 @@ void __devinit pci_read_bridge_bases(str
res->start = base;
if (!res->end)
res->end = limit + 0xfff;
- printk(KERN_INFO "PCI: bridge %s io port: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
+ printk(KERN_DEBUG "PCI: bridge %s io port: [%llx, %llx]\n",
+ pci_name(dev), res->start, res->end);
}
res = child->resource[1];
@@ -395,7 +402,8 @@ void __devinit pci_read_bridge_bases(str
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
res->start = base;
res->end = limit + 0xfffff;
- printk(KERN_INFO "PCI: bridge %s 32bit mmio: [%llx, %llx]\n", pci_name(dev), res->start, res->end);
+ printk(KERN_DEBUG "PCI: bridge %s 32bit mmio: [%llx, %llx]\n",
+ pci_name(dev), res->start, res->end);
}
res = child->resource[2];
@@ -431,7 +439,9 @@ void __devinit pci_read_bridge_bases(str
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH;
res->start = base;
res->end = limit + 0xfffff;
- printk(KERN_INFO "PCI: bridge %s %sbit mmio pref: [%llx, %llx]\n", pci_name(dev), (res->flags & PCI_PREF_RANGE_TYPE_64)?"64":"32",res->start, res->end);
+ printk(KERN_DEBUG "PCI: bridge %s %sbit mmio pref: [%llx, %llx]\n",
+ pci_name(dev), (res->flags & PCI_PREF_RANGE_TYPE_64)?"64":"32",
+ res->start, res->end);
}
}
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: split_e820_reserve.patch --]
[-- Type: text/x-patch; name=split_e820_reserve.patch, Size: 3574 bytes --]
From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: split e820 reserved entries record to late v4
Linus said we should register some entries in e820 later,
so could let BAR res register at first, or even pnp?
this one replace
| commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date: Mon Aug 25 00:56:08 2008 -0700
|
| x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3
v2: insert e820 reserve resources before pnp_system_init
v3: fix merging problem in tip/x86/core
please drop the one in tip/x86/core use this one instead
v4: address Linus's review about comments and condition in _late()
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
arch/x86/kernel/e820.c | 24 +++++++++++++++++++++++-
arch/x86/pci/i386.c | 3 +++
include/asm-x86/e820.h | 1 +
3 files changed, 27 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1267,6 +1267,7 @@ static inline const char *e820_type_to_s
/*
* Mark e820 reserved areas as busy for the resource manager.
*/
+static struct resource __initdata *e820_res;
void __init e820_reserve_resources(void)
{
int i;
@@ -1274,6 +1275,7 @@ void __init e820_reserve_resources(void)
u64 end;
res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
+ e820_res = res;
for (i = 0; i < e820.nr_map; i++) {
end = e820.map[i].addr + e820.map[i].size - 1;
#ifndef CONFIG_RESOURCES_64BIT
@@ -1287,7 +1289,14 @@ void __init e820_reserve_resources(void)
res->end = end;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- insert_resource(&iomem_resource, res);
+
+ /*
+ * don't register the region that could be conflicted with
+ * pci device BAR resource and insert them later in
+ * pcibios_resource_survey()
+ */
+ if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20))
+ insert_resource(&iomem_resource, res);
res++;
}
@@ -1299,6 +1308,19 @@ void __init e820_reserve_resources(void)
}
}
+void __init e820_reserve_resources_late(void)
+{
+ int i;
+ struct resource *res;
+
+ res = e820_res;
+ for (i = 0; i < e820.nr_map; i++) {
+ if (!res->parent && res->end)
+ insert_resource(&iomem_resource, res);
+ res++;
+ }
+}
+
char *__init default_machine_specific_memory_setup(void)
{
char *who = "BIOS-e820";
Index: linux-2.6/arch/x86/pci/i386.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/i386.c
+++ linux-2.6/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
#include <linux/bootmem.h>
#include <asm/pat.h>
+#include <asm/e820.h>
#include "pci.h"
@@ -230,6 +231,8 @@ void __init pcibios_resource_survey(void
pcibios_allocate_bus_resources(&pci_root_buses);
pcibios_allocate_resources(0);
pcibios_allocate_resources(1);
+
+ e820_reserve_resources_late();
}
/**
Index: linux-2.6/include/asm-x86/e820.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820.h
+++ linux-2.6/include/asm-x86/e820.h
@@ -120,6 +120,7 @@ extern void e820_register_active_regions
extern u64 e820_hole_size(u64 start, u64 end);
extern void finish_e820_parsing(void);
extern void e820_reserve_resources(void);
+extern void e820_reserve_resources_late(void);
extern void setup_memory_map(void);
extern char *default_machine_specific_memory_setup(void);
extern char *machine_specific_memory_setup(void);
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: split_e820_reserve_xx2.patch --]
[-- Type: text/x-patch; name=split_e820_reserve_xx2.patch, Size: 5150 bytes --]
From: Yinghai Lu <yhlu.kernel@gmail.com>
Subject: [PATCH] x86: split e820 reserved entries record to late v4 - fix v7
try to insert_resource second time, by expand the resource...
for case: e820 reserved entry is partially overlapped with bar res...
hope it will never happen
v2: according to Linus, add insert_resource_expand_to_fit, and change
__insert_resource to static without lock
v3: use reserve_region_with_split() instead to hand overlapping
with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 -
get
e0000000-efffffff : PCI MMCONFIG 0
e0000000-efffffff : reserved
in /proc/iomem
get
found conflict for reserved [dd800000, efffffff], try to reserve with split
__reserve_region_with_split: (PCI Bus #80) [dd000000, ddffffff], res: (reserved) [dd800000, efffffff]
__reserve_region_with_split: (PCI Bus #00) [de000000, dfffffff], res: (reserved) [de000000, efffffff]
initcall pci_subsys_init+0x0/0x121 returned 0 after 381 msecs
in dmesg
v4: take out __insert_resource and insert_resource_expand_to_fit : Linus already check in.
use reserve_region_with_split at the first point
use const char *name
v5: fix checking on overlapping
v6: only reserve common area in conflict
so got sth in /proc/iomem
d8000000-dfffffff : PCI Bus #00
dc000000-dfffffff : GART
dc000000-dfffffff : reserved
e0000000-efffffff : PCI MMCONFIG 0
e0000000-efffffff : reserved
when we have big range in e820
00000000dc000000-00000000f0000000 (reserved)
v7: remove wrong removing of write_unlock(&resource_lock) in adjust_resource()
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
arch/x86/kernel/e820.c | 2 -
include/linux/ioport.h | 3 ++
kernel/resource.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 72 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1320,7 +1320,7 @@ void __init e820_reserve_resources_late(
res = e820_res;
for (i = 0; i < e820.nr_map; i++) {
if (!res->parent && res->end)
- insert_resource(&iomem_resource, res);
+ reserve_region_with_split(&iomem_resource, res->start, res->end, res->name);
res++;
}
}
Index: linux-2.6/include/linux/ioport.h
===================================================================
--- linux-2.6.orig/include/linux/ioport.h
+++ linux-2.6/include/linux/ioport.h
@@ -108,6 +108,9 @@ extern struct resource iomem_resource;
extern int request_resource(struct resource *root, struct resource *new);
extern int release_resource(struct resource *new);
+extern void reserve_region_with_split(struct resource *root,
+ resource_size_t start, resource_size_t end,
+ const char *name);
extern int insert_resource(struct resource *parent, struct resource *new);
extern void insert_resource_expand_to_fit(struct resource *root, struct resource *new);
extern int allocate_resource(struct resource *root, struct resource *new,
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -516,6 +516,74 @@ int adjust_resource(struct resource *res
return result;
}
+static void __init __reserve_region_with_split(struct resource *root,
+ resource_size_t start, resource_size_t end,
+ const char *name)
+{
+ struct resource *parent = root;
+ struct resource *conflict;
+ struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL);
+
+ if (!res)
+ return;
+
+ res->name = name;
+ res->start = start;
+ res->end = end;
+ res->flags = IORESOURCE_BUSY;
+
+ for (;;) {
+ conflict = __request_resource(parent, res);
+ if (!conflict)
+ break;
+ if (conflict != parent) {
+ parent = conflict;
+ if (!(conflict->flags & IORESOURCE_BUSY))
+ continue;
+ }
+
+ /* Uhhuh, that didn't work out.. */
+ kfree(res);
+ res = NULL;
+ break;
+ }
+
+ if (!res) {
+ printk(KERN_DEBUG " __reserve_region_with_split: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n",
+ conflict->name, conflict->start, conflict->end,
+ name, start, end);
+
+ /* failed, split and try again */
+
+ /* conflict coverred whole area */
+ if (conflict->start <= start && conflict->end >= end)
+ return;
+
+ if (conflict->start > start)
+ __reserve_region_with_split(root, start, conflict->start-1, name);
+ if (!(conflict->flags & IORESOURCE_BUSY)) {
+ resource_size_t common_start, common_end;
+
+ common_start = max(conflict->start, start);
+ common_end = min(conflict->end, end);
+ if (common_start < common_end)
+ __reserve_region_with_split(root, common_start, common_end, name);
+ }
+ if (conflict->end < end)
+ __reserve_region_with_split(root, conflict->end+1, end, name);
+ }
+
+}
+
+void reserve_region_with_split(struct resource *root,
+ resource_size_t start, resource_size_t end,
+ const char *name)
+{
+ write_lock(&resource_lock);
+ __reserve_region_with_split(root, start, end, name);
+ write_unlock(&resource_lock);
+}
+
EXPORT_SYMBOL(adjust_resource);
/**
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: insert_resource_debug_x.patch --]
[-- Type: text/x-patch; name=insert_resource_debug_x.patch, Size: 3755 bytes --]
---
kernel/resource.c | 27 ++++++++++++++++++++++-----
1 file changed, 22 insertions(+), 5 deletions(-)
Index: linux-2.6/kernel/resource.c
===================================================================
--- linux-2.6.orig/kernel/resource.c
+++ linux-2.6/kernel/resource.c
@@ -201,6 +201,7 @@ int request_resource(struct resource *ro
write_lock(&resource_lock);
conflict = __request_resource(root, new);
write_unlock(&resource_lock);
+ printk(KERN_DEBUG "request_resource: root: (%s) [%llx, %llx], new: (%s) [%llx, %llx] conflict %d\n", root->name, root->start, root->end, new->name, new->start, new->end, !!conflict);
return conflict ? -EBUSY : 0;
}
@@ -372,12 +373,16 @@ static struct resource * __insert_resour
for (;; parent = first) {
first = __request_resource(parent, new);
- if (!first)
+ if (!first) {
+ printk(KERN_DEBUG " insert_resource: good with request direct parent: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, new->name, new->start, new->end);
+
return first;
+ }
if (first == parent)
return first;
+ printk(KERN_DEBUG " insert_resource: first: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", first->name, first->start, first->end, new->name, new->start, new->end);
if ((first->start > new->start) || (first->end < new->end))
break;
if ((first->start == new->start) && (first->end == new->end))
@@ -397,10 +402,13 @@ static struct resource * __insert_resour
new->parent = parent;
new->sibling = next->sibling;
new->child = first;
+ printk(KERN_DEBUG " insert_resource: direct parent: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, new->name, new->start, new->end);
next->sibling = NULL;
- for (next = first; next; next = next->sibling)
+ for (next = first; next; next = next->sibling) {
next->parent = new;
+ printk(KERN_DEBUG " insert_resource: child: (%s) [%llx, %llx], new: (%s) [%llx, %llx]\n", next->name, next->start, next->end, new->name, new->start, new->end);
+ }
if (parent->child == first) {
parent->child = new;
@@ -533,8 +541,13 @@ static void __init __reserve_region_with
for (;;) {
conflict = __request_resource(parent, res);
- if (!conflict)
+ if (!conflict) {
+ printk(KERN_DEBUG " __reserve_region_with_split: good with request direct parent: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n",
+ parent->name, parent->start, parent->end,
+ name, start, end);
+
break;
+ }
if (conflict != parent) {
parent = conflict;
if (!(conflict->flags & IORESOURCE_BUSY))
@@ -548,7 +561,7 @@ static void __init __reserve_region_with
}
if (!res) {
- printk(KERN_DEBUG " __reserve_region_with_split: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n",
+ printk(KERN_DEBUG " __reserve_region_with_split: conflict: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n",
conflict->name, conflict->start, conflict->end,
name, start, end);
@@ -641,12 +654,16 @@ struct resource * __request_region(struc
struct resource *conflict;
conflict = __request_resource(parent, res);
- if (!conflict)
+ if (!conflict) {
+ printk(KERN_DEBUG " __request_region: good with request direct parent: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n", parent->name, parent->start, parent->end, res->name, res->start, res->end);
break;
+ }
if (conflict != parent) {
+ printk(KERN_DEBUG " __request_region: conflict: (%s) [%llx, %llx], res: (%s) [%llx, %llx]\n", conflict->name, conflict->start, conflict->end, res->name, res->start, res->end);
parent = conflict;
if (!(conflict->flags & IORESOURCE_BUSY))
continue;
+ printk(KERN_DEBUG "busy flag\n");
}
/* Uhhuh, that didn't work out.. */
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 6:01 ` Andrew Morton
@ 2008-09-04 7:15 ` Andrew Morton
2008-09-04 7:48 ` Stephen Rothwell
` (4 more replies)
0 siblings, 5 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 7:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds, David Woodhouse, Alan Cox
On Wed, 3 Sep 2008 23:01:29 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> I'll see if I cen reproduce the bug I'm
> actually tring to find with E100=n.
OK, this regression[*] bisects down to
commit b689ad2b010f09626a6158e1213a075a1aa9f299
Author: Alan Cox <alan@redhat.com>
Date: Wed Sep 3 10:12:18 2008 +1000
tty-kref-get-current-tty
We now return a kref covered tty reference. That ensures the tty structure
doesn't go away when you have a return from get_current_tty. This is not
enough to protect you from most of the resources being freed behind your
back - yet.
This got a bit ugly, because tty-kref-get-current-tty fixes a pile of
compilation errors which were introduced in the innediately preceding
patch (tty-kref-modcount, I think). I roughly fixed those up by hand:
--- a/drivers/char/tty_io.c~b
+++ a/drivers/char/tty_io.c
@@ -1283,7 +1283,7 @@ static int init_dev(struct tty_driver *d
o_tty = alloc_tty_struct();
if (!o_tty)
goto free_mem_out;
- if (!try_module_get(driver->other)) {
+ if (!try_module_get(driver->owner)) {
/* This cannot in fact currently happen */
free_tty_struct(o_tty);
o_tty = NULL;
@@ -1408,7 +1408,7 @@ end_init:
free_mem_out:
kfree(o_tp);
if (o_tty) {
- module_put(o_tty->driver);
+ module_put(o_tty->driver->owner);
free_tty_struct(o_tty);
}
kfree(ltp);
@@ -1469,7 +1469,7 @@ static void release_one_tty(struct kref
tty->magic = 0;
/* FIXME: locking on tty->driver->refcount */
tty->driver->refcount--;
- module_put(driver->owner);
+ module_put(tty->driver->owner);
file_list_lock();
list_del_init(&tty->tty_files);
_
I cannot find any of these patches on a mailing list.
I cannot revert tty-kref-get-current-tty and I can't immediately spot
the bug in it.
I could revert the whole tty tree, but I'd prefer that you do it,
please. I've been trying for two days to get a -mm out, but I'm
building on a foundation of straw :(
[*] symptoms: there are no login prompts appearing on the VT consoles.
sshd works OK (will it did, but I had to disable the net driver due to
networking bisect breakage).
config: http://userweb.kernel.org/~akpm/config-sony.txt
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-2.txt
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:15 ` Andrew Morton
@ 2008-09-04 7:48 ` Stephen Rothwell
2008-09-04 9:19 ` Alan Cox
` (3 subsequent siblings)
4 siblings, 0 replies; 53+ messages in thread
From: Stephen Rothwell @ 2008-09-04 7:48 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, LKML, Yinghai Lu, Linus Torvalds, David Woodhouse, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
Hi Andrew,
On Thu, 4 Sep 2008 00:15:58 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I cannot find any of these patches on a mailing list.
Hmmm ...
> I cannot revert tty-kref-get-current-tty and I can't immediately spot
> the bug in it.
Yeah, it is a bit involved and caught up.
> I could revert the whole tty tree, but I'd prefer that you do it,
> please. I've been trying for two days to get a -mm out, but I'm
> building on a foundation of straw :(
OK, I have done that for today ... this is an actual revert (as I don't
have time this evening to go back and remerge everything after the ttydev
tree) so there is a bisect hole between when the tree gets merged and
when it gets reverted (not actually very large, but I though it was worth
mentioning).
--
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 [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:14 ` Yinghai Lu
@ 2008-09-04 8:00 ` Andrew Morton
2008-09-04 8:23 ` Linus Torvalds
1 sibling, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 8:00 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Linus Torvalds, Stephen Rothwell, linux-next, LKML
On Thu, 4 Sep 2008 00:14:18 -0700 "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> wonder if some pci code change cause that.... doesn't get pref mem assigned.
>
> can you apply attached patches to get more dump?
Your fourth patch produces a great storm of printk warnings and the
machine immediately locks up. Setting CONFIG_RESOURCES_64BIT=y fixes
this.
How many of these damn printk warnings do I have to fix? They're not
just cosmetic! They are real bugs which can cause callees to read
incoming arguments from incorrect stack offsets. Sigh.
dmesg for mainline:
http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
dmesg with the four patches applied:
http://userweb.kernel.org/~akpm/dmesg-sony-with.txt
roughly edited diff:
--- dmesg-sony-without.txt 2008-09-04 00:57:16.000000000 -0700
+++ dmesg-sony-with.txt 2008-09-04 00:50:06.000000000 -0700
@@ -1,4 +1,4 @@
-Linux version 2.6.27-rc5 (akpm@y.localdomain) (gcc version 4.1.0) #11 PREEMPT Thu Sep 4 00:52:48 PDT 2008
+Linux version 2.6.27-rc5 (akpm@y.localdomain) (gcc version 4.1.0) #10 PREEMPT Thu Sep 4 00:45:32 PDT 2008
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
@@ -13,9 +13,14 @@
BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
console [earlyvga0] enabled
debug: ignoring loglevel setting.
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (Video ROM) [c0000, c7fff] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (System ROM) [f0000, fffff] conflict 0
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel code) [100000, 327f7a]
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel data) [327f7b, 467f9f]
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (Kernel bss) [4a3000, abfa93]
last_pfn = 0x3f690 max_arch_pfn = 0x100000
kernel direct mapping tables up to 38000000 @ 7000-c000
-RAMDISK: 37f0d000 - 37fef835
+RAMDISK: 37f0d000 - 37fef838
DMI 2.3 present.
ACPI: RSDP 000F6780, 0014 (r0 PTLTD )
ACPI: RSDT 3F697449, 0048 (r1 Sony V0 20051108 PTL 0)
@@ -39,7 +44,7 @@
(7 early reservations) ==> bootmem [0000000000 - 0038000000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0000100000 - 0000abfa94] TEXT DATA BSS ==> [0000100000 - 0000abfa94]
- #2 [0037f0d000 - 0037fef835] RAMDISK ==> [0037f0d000 - 0037fef835]
+ #2 [0037f0d000 - 0037fef838] RAMDISK ==> [0037f0d000 - 0037fef838]
#3 [0000ac0000 - 0000ac4000] INIT_PG_TABLE ==> [0000ac0000 - 0000ac4000]
#4 [000009f800 - 0000100000] BIOS reserved ==> [000009f800 - 0000100000]
#5 [0000007000 - 0000008000] PGTABLE ==> [0000007000 - 0000008000]
@@ -53,7 +58,7 @@
0: 0x00000000 -> 0x0000009f
0: 0x00000100 -> 0x0003f690
On node 0 totalpages: 259631
-free_area_init_node: node 0, pgdat c045ecc0, node_mem_map c1000000
+free_area_init_node: node 0, pgdat c045fcc0, node_mem_map c1000000
DMA zone: 3967 pages, LIFO batch:0
Normal zone: 223520 pages, LIFO batch:31
HighMem zone: 30114 pages, LIFO batch:7
@@ -74,9 +79,32 @@
Using ACPI (MADT) for SMP configuration information
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (System RAM) [0, 9f7ff]
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (reserved) [9f800, 9ffff]
+ insert_resource: first: (System ROM) [f0000, fffff], new: (reserved) [d8000, fffff]
+ insert_resource: direct parent: (PCI mem) [0, ffffffffffffffff], new: (reserved) [d8000, fffff]
+ insert_resource: child: (System ROM) [f0000, fffff], new: (reserved) [d8000, fffff]
+ insert_resource: first: (Kernel code) [100000, 327f7a], new: (System RAM) [100000, 3f68ffff]
+ insert_resource: direct parent: (PCI mem) [0, ffffffffffffffff], new: (System RAM) [100000, 3f68ffff]
+ insert_resource: child: (Kernel code) [100000, 327f7a], new: (System RAM) [100000, 3f68ffff]
+ insert_resource: child: (Kernel data) [327f7b, 467f9f], new: (System RAM) [100000, 3f68ffff]
+ insert_resource: child: (Kernel bss) [4a3000, abfa93], new: (System RAM) [100000, 3f68ffff]
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (ACPI Tables) [3f690000, 3f69cfff]
+ insert_resource: good with request direct parent: (PCI mem) [0, ffffffffffffffff], new: (ACPI Non-volatile Storage) [3f69d000, 3f6fffff]
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000d8000
PM: Registered nosave memory: 00000000000d8000 - 0000000000100000
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (Video RAM area) [a0000, bffff] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (dma1) [0, 1f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (pic1) [20, 21] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (timer0) [40, 43] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (timer1) [50, 53] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (keyboard) [60, 60] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (keyboard) [64, 64] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (dma page reg) [80, 8f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (pic2) [a0, a1] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (dma2) [c0, df] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (fpu) [f0, ff] conflict 0
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 257601
Kernel command line: ro root=LABEL=/ initcall_debug rhgb vga=0x263 netconsole=4444@192.168.2.10/eth0,5145@192.168.2.111/00:19:D1:04:8F:42 profile=1 earlyprintk=vga resume=8:5 lapic nmi_watchdog=2 ignore_loglevel
@@ -211,6 +239,7 @@
calling dmi_id_init+0x0/0x26b
initcall dmi_id_init+0x0/0x26b returned 0 after 0 msecs
calling pci_arch_init+0x0/0x4a
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (PCI conf1) [cf8, cff]
PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
PCI: MCFG area at e0000000 reserved in E820
PCI: Using MMCONFIG for extended config space
@@ -253,31 +282,63 @@
initcall acpi_ec_init+0x0/0x55 returned 0 after 0 msecs
calling acpi_pci_root_init+0x0/0x25
ACPI: PCI Root Bridge [PCI0] (0000:00)
+PCI: 0000:00:02.0 reg 10 32bit mmio: [b0080000, b00fffff]
+PCI: 0000:00:02.0 reg 14 io port: [1800, 1807]
+PCI: 0000:00:02.0 reg 18 32bit mmio: [c0000000, cfffffff]
+PCI: 0000:00:02.0 reg 1c 32bit mmio: [b0040000, b007ffff]
+PCI: 0000:00:02.1 reg 10 32bit mmio: [0, 7ffff]
+PCI: 0000:00:1b.0 reg 10 64bit mmio: [b0000000, b0003fff]
pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1b.0: PME# disabled
+PCI: 0000:00:1d.0 reg 20 io port: [1820, 183f]
+PCI: 0000:00:1d.1 reg 20 io port: [1840, 185f]
+PCI: 0000:00:1d.2 reg 20 io port: [1860, 187f]
+PCI: 0000:00:1d.3 reg 20 io port: [1880, 189f]
+PCI: 0000:00:1d.7 reg 10 32bit mmio: [b0004000, b00043ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:00:1f.0: Force enabled HPET at 0xfed00000
+ insert_resource: good with request direct parent: (PCI IO) [0, ffff], new: (0000:00:1f.0) [1000, 107f]
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
+ insert_resource: good with request direct parent: (PCI IO) [0, ffff], new: (0000:00:1f.0) [1180, 11bf]
pci 0000:00:1f.0: quirk: region 1180-11bf claimed by ICH6 GPIO
+PCI: 0000:00:1f.1 reg 10 io port: [0, 7]
+PCI: 0000:00:1f.1 reg 14 io port: [0, 3]
+PCI: 0000:00:1f.1 reg 18 io port: [0, 7]
+PCI: 0000:00:1f.1 reg 1c io port: [0, 3]
+PCI: 0000:00:1f.1 reg 20 io port: [1810, 181f]
+PCI: 0000:00:1f.2 reg 10 io port: [18c8, 18cf]
+PCI: 0000:00:1f.2 reg 14 io port: [18c0, 18c3]
+PCI: 0000:00:1f.2 reg 18 io port: [18a8, 18af]
+PCI: 0000:00:1f.2 reg 1c io port: [180c, 180f]
+PCI: 0000:00:1f.2 reg 20 io port: [18b0, 18bf]
+PCI: 0000:00:1f.2 reg 24 32bit mmio: [b0004400, b00047ff]
pci 0000:00:1f.2: PME# supported from D3hot
pci 0000:00:1f.2: PME# disabled
+PCI: 0000:00:1f.3 reg 20 io port: [18e0, 18ff]
+PCI: 0000:06:05.0 reg 10 32bit mmio: [0, fff]
pci 0000:06:05.0: supports D1
pci 0000:06:05.0: supports D2
pci 0000:06:05.0: PME# supported from D0 D1 D2 D3hot
pci 0000:06:05.0: PME# disabled
+PCI: 0000:06:05.2 reg 10 32bit mmio: [b0104000, b01047ff]
+PCI: 0000:06:05.2 reg 14 32bit mmio: [b0100000, b0103fff]
pci 0000:06:05.2: supports D1
pci 0000:06:05.2: supports D2
pci 0000:06:05.2: PME# supported from D0 D1 D2 D3hot
pci 0000:06:05.2: PME# disabled
+PCI: 0000:06:05.3 reg 10 32bit mmio: [b0105000, b0105fff]
pci 0000:06:05.3: supports D1
pci 0000:06:05.3: supports D2
pci 0000:06:05.3: PME# supported from D0 D1 D2 D3hot
pci 0000:06:05.3: PME# disabled
+PCI: 0000:06:08.0 reg 10 32bit mmio: [b0106000, b0106fff]
+PCI: 0000:06:08.0 reg 14 io port: [2000, 203f]
pci 0000:06:08.0: supports D1
pci 0000:06:08.0: supports D2
pci 0000:06:08.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:06:08.0: PME# disabled
+PCI: 0000:06:0b.0 reg 10 32bit mmio: [b0107000, b0107fff]
pci 0000:06:0b.0: PME# supported from D0 D3hot D3cold
pci 0000:06:0b.0: PME# disabled
pci 0000:00:1e.0: transparent bridge
@@ -337,6 +398,41 @@
initcall thermal_init+0x0/0x46 returned 0 after 0 msecs
calling pci_subsys_init+0x0/0xe4
PCI: Using ACPI for IRQ routing
+request_resource: root: (PCI IO) [0, ffff], new: (PCI Bus 0000:06) [2000, 2fff] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (PCI Bus 0000:06) [b0100000, b01fffff] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:02.0) [b0080000, b00fffff] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:02.0) [1800, 1807] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:02.0) [c0000000, cfffffff] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:02.0) [b0040000, b007ffff] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:1b.0) [b0000000, b0003fff] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1d.0) [1820, 183f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1d.1) [1840, 185f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1d.2) [1860, 187f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1d.3) [1880, 189f] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:1d.7) [b0004000, b00043ff] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.1) [1f0, 1f7] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.1) [3f6, 3f6] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.1) [170, 177] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.1) [376, 376] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.1) [1810, 181f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.2) [18c8, 18cf] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.2) [18c0, 18c3] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.2) [18a8, 18af] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.2) [180c, 180f] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.2) [18b0, 18bf] conflict 0
+request_resource: root: (PCI mem) [0, ffffffffffffffff], new: (0000:00:1f.2) [b0004400, b00047ff] conflict 0
+request_resource: root: (PCI IO) [0, ffff], new: (0000:00:1f.3) [18e0, 18ff] conflict 0
+request_resource: root: (PCI Bus 0000:06) [b0100000, b01fffff], new: (0000:06:05.2) [b0104000, b01047ff] conflict 0
+request_resource: root: (PCI Bus 0000:06) [b0100000, b01fffff], new: (0000:06:05.2) [b0100000, b0103fff] conflict 0
+request_resource: root: (PCI Bus 0000:06) [b0100000, b01fffff], new: (0000:06:05.3) [b0105000, b0105fff] conflict 0
+request_resource: root: (PCI Bus 0000:06) [b0100000, b01fffff], new: (0000:06:08.0) [b0106000, b0106fff] conflict 0
+request_resource: root: (PCI Bus 0000:06) [2000, 2fff], new: (0000:06:08.0) [2000, 203f] conflict 0
+request_resource: root: (PCI Bus 0000:06) [b0100000, b01fffff], new: (0000:06:0b.0) [b0107000, b0107fff] conflict 0
+ __reserve_region_with_split: good with request direct parent: (PCI mem) [0, ffffffffffffffff], res: (reserved) [3f700000, 3fffffff]
+ __reserve_region_with_split: good with request direct parent: (PCI mem) [0, ffffffffffffffff], res: (reserved) [e0000000, f0005fff]
+ __reserve_region_with_split: good with request direct parent: (PCI mem) [0, ffffffffffffffff], res: (reserved) [f0008000, f000bfff]
+ __reserve_region_with_split: good with request direct parent: (PCI mem) [0, ffffffffffffffff], res: (reserved) [fed20000, fed8ffff]
+ __reserve_region_with_split: good with request direct parent: (PCI mem) [0, ffffffffffffffff], res: (reserved) [ff000000, ffffffff]
initcall pci_subsys_init+0x0/0xe4 returned 0 after 0 msecs
calling proto_init+0x0/0x27
initcall proto_init+0x0/0x27 returned 0 after 0 msecs
@@ -387,21 +483,41 @@
calling acpi_event_init+0x0/0x6f
initcall acpi_event_init+0x0/0x6f returned 0 after 0 msecs
calling pnp_system_init+0x0/0xf
+ __request_region: conflict: (reserved) [e0000000, f0005fff], res: (pnp 00:01) [e0000000, efffffff]
+busy flag
system 00:01: iomem range 0xe0000000-0xefffffff could not be reserved
+ __request_region: conflict: (reserved) [e0000000, f0005fff], res: (pnp 00:01) [f0000000, f0003fff]
+busy flag
system 00:01: iomem range 0xf0000000-0xf0003fff could not be reserved
+ __request_region: conflict: (reserved) [e0000000, f0005fff], res: (pnp 00:01) [f0004000, f0004fff]
+busy flag
system 00:01: iomem range 0xf0004000-0xf0004fff could not be reserved
+ __request_region: conflict: (reserved) [e0000000, f0005fff], res: (pnp 00:01) [f0005000, f0005fff]
+busy flag
system 00:01: iomem range 0xf0005000-0xf0005fff could not be reserved
+ __request_region: conflict: (reserved) [f0008000, f000bfff], res: (pnp 00:01) [f0008000, f000bfff]
+busy flag
system 00:01: iomem range 0xf0008000-0xf000bfff could not be reserved
+ __request_region: conflict: (reserved) [fed20000, fed8ffff], res: (pnp 00:01) [fed20000, fed8ffff]
+busy flag
system 00:01: iomem range 0xfed20000-0xfed8ffff could not be reserved
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (pnp 00:05) [680, 68f]
system 00:05: ioport range 0x680-0x68f has been reserved
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (pnp 00:05) [800, 80f]
system 00:05: ioport range 0x800-0x80f has been reserved
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (pnp 00:05) [1000, 107f]
+ __request_region: good with request direct parent: (0000:00:1f.0) [1000, 107f], res: (pnp 00:05) [1000, 107f]
system 00:05: ioport range 0x1000-0x107f has been reserved
+ __request_region: conflict: (0000:00:1f.0) [1180, 11bf], res: (pnp 00:05) [1180, 11bf]
+ __request_region: good with request direct parent: (0000:00:1f.0) [1180, 11bf], res: (pnp 00:05) [1180, 11bf]
system 00:05: ioport range 0x1180-0x11bf has been reserved
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (pnp 00:05) [fe00, fe01]
system 00:05: ioport range 0xfe00-0xfe01 has been reserved
+ __request_region: good with request direct parent: (PCI mem) [0, ffffffffffffffff], res: (pnp 00:05) [d000c000, d000ffff]
system 00:05: iomem range 0xd000c000-0xd000ffff has been reserved
initcall pnp_system_init+0x0/0xf returned 0 after 0 msecs
calling chr_dev_init+0x0/0x8b
-initcall chr_dev_init+0x0/0x8b returned 0 after 4 msecs
+initcall chr_dev_init+0x0/0x8b returned 0 after 0 msecs
calling firmware_class_init+0x0/0x61
initcall firmware_class_init+0x0/0x61 returned 0 after 0 msecs
calling loopback_init+0x0/0xf
@@ -634,36 +750,57 @@
calling fb_console_init+0x0/0xf5
initcall fb_console_init+0x0/0xf5 returned 0 after 0 msecs
calling vesafb_init+0x0/0x1f3
+ __request_region: conflict: (0000:00:02.0) [c0000000, cfffffff], res: (vesafb) [c0000000, c07affff]
+ __request_region: good with request direct parent: (0000:00:02.0) [c0000000, cfffffff], res: (vesafb) [c0000000, c07affff]
vesafb: framebuffer at 0xc0000000, mapped to 0xf8880000, using 2000k, total 7872k
vesafb: mode is 1280x800x8, linelength=1280, pages=6
vesafb: scrolling: redraw
vesafb: Pseudocolor: size=8:8:8:8, shift=0:0:0:0
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (vesafb) [3c0, 3df]
Console: switching to colour frame buffer device 160x50
fb0: VESA VGA frame buffer device
initcall vesafb_init+0x0/0x1f3 returned 0 after 23 msecs
calling acpi_reserve_resources+0x0/0xc8
-initcall acpi_reserve_resources+0x0/0xc8 returned 0 after 0 msecs
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (ACPI PM1a_EVT_BLK) [1000, 1003]
+ __request_region: conflict: (pnp 00:05) [1000, 107f], res: (ACPI PM1a_EVT_BLK) [1000, 1003]
+ __request_region: good with request direct parent: (pnp 00:05) [1000, 107f], res: (ACPI PM1a_EVT_BLK) [1000, 1003]
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (ACPI PM1a_CNT_BLK) [1004, 1005]
+ __request_region: conflict: (pnp 00:05) [1000, 107f], res: (ACPI PM1a_CNT_BLK) [1004, 1005]
+ __request_region: good with request direct parent: (pnp 00:05) [1000, 107f], res: (ACPI PM1a_CNT_BLK) [1004, 1005]
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (ACPI PM_TMR) [1008, 100b]
+ __request_region: conflict: (pnp 00:05) [1000, 107f], res: (ACPI PM_TMR) [1008, 100b]
+ __request_region: good with request direct parent: (pnp 00:05) [1000, 107f], res: (ACPI PM_TMR) [1008, 100b]
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (ACPI PM2_CNT_BLK) [1020, 1020]
+ __request_region: conflict: (pnp 00:05) [1000, 107f], res: (ACPI PM2_CNT_BLK) [1020, 1020]
+ __request_region: good with request direct parent: (pnp 00:05) [1000, 107f], res: (ACPI PM2_CNT_BLK) [1020, 1020]
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (ACPI GPE0_BLK) [1028, 102f]
+ __request_region: conflict: (pnp 00:05) [1000, 107f], res: (ACPI GPE0_BLK) [1028, 102f]
+ __request_region: good with request direct parent: (pnp 00:05) [1000, 107f], res: (ACPI GPE0_BLK) [1028, 102f]
+initcall acpi_reserve_resources+0x0/0xc8 returned 0 after 2 msecs
calling acpi_ac_init+0x0/0x3d
ACPI: AC Adapter [ACAD] (on-line)
-initcall acpi_ac_init+0x0/0x3d returned 0 after 1 msecs
+initcall acpi_ac_init+0x0/0x3d returned 0 after 5 msecs
calling acpi_battery_init+0x0/0x3d
ACPI: Battery Slot [BAT1] (battery present)
-initcall acpi_battery_init+0x0/0x3d returned 0 after 5 msecs
+initcall acpi_battery_init+0x0/0x3d returned 0 after 10 msecs
calling acpi_fan_init+0x0/0x51
initcall acpi_fan_init+0x0/0x51 returned 0 after 0 msecs
calling irqrouter_init_sysfs+0x0/0x33
initcall irqrouter_init_sysfs+0x0/0x33 returned 0 after 0 msecs
calling acpi_processor_init+0x0/0x79
+ __request_region: conflict: (0000:00:1f.0) [1000, 107f], res: (ACPI CPU throttle) [1010, 1015]
+ __request_region: conflict: (pnp 00:05) [1000, 107f], res: (ACPI CPU throttle) [1010, 1015]
+ __request_region: good with request direct parent: (pnp 00:05) [1000, 107f], res: (ACPI CPU throttle) [1010, 1015]
ACPI: CPU0 (power states: C1[C1] C2[C2])
processor ACPI0007:00: registered as cooling_device0
ACPI: Processor [CPU0] (supports 8 throttling states)
-initcall acpi_processor_init+0x0/0x79 returned 0 after 1 msecs
...
calling serial8250_init+0x0/0x10c
Serial: 8250/16550 driver4 ports, IRQ sharing enabled
-initcall serial8250_init+0x0/0x10c returned 0 after 4 msecs
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial) [3f8, 3ff]
+ __request_region: conflict: (0000:00:1f.1) [3f6, 3f6], res: (serial-rsa) [3f0, 3f7]
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial) [2f8, 2ff]
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial-rsa) [2f0, 2f7]
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial) [3e8, 3ef]
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial-rsa) [3e0, 3e7]
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial) [2e8, 2ef]
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (serial-rsa) [2e0, 2e7]
+initcall serial8250_init+0x0/0x10c returned 0 after 31 msecs
calling serial8250_pnp_init+0x0/0xf
initcall serial8250_pnp_init+0x0/0xf returned 0 after 0 msecs
calling serial8250_pci_init+0x0/0x16
@@ -696,15 +842,22 @@
input: Sony Vaio Keys as /class/input/input0
input: Sony Vaio Jogdial as /class/input/input1
sony-laptop: device allocated minor is 63
+ __request_region: good with request direct parent: (PCI IO) [0, ffff], res: (Sony Programable I/O Device) [1080, 109f]
sony-laptop: Sony Notebook Control Driver v0.6.
-initcall sony_laptop_init+0x0/0x6d returned 0 after 21 msecs
+initcall sony_laptop_init+0x0/0x6d returned 0 after 27 msecs
calling e100_init_module+0x0/0x4d
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:06:08.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ __request_region: conflict: (PCI Bus 0000:06) [b0100000, b01fffff], res: (e100) [b0106000, b0106fff]
+ __request_region: conflict: (0000:06:08.0) [b0106000, b0106fff], res: (e100) [b0106000, b0106fff]
+ __request_region: good with request direct parent: (0000:06:08.0) [b0106000, b0106fff], res: (e100) [b0106000, b0106fff]
+ __request_region: conflict: (PCI Bus 0000:06) [2000, 2fff], res: (e100) [2000, 203f]
+ __request_region: conflict: (0000:06:08.0) [2000, 203f], res: (e100) [2000, 203f]
+ __request_region: good with request direct parent: (0000:06:08.0) [2000, 203f], res: (e100) [2000, 203f]
e100: 0000:06:08.0: e100_probe: Error clearing wake event
e100: eth0: e100_probe: addr 0xb0106000, irq 20, MAC addr 00:01:4a:9f:7c:79
-initcall e100_init_module+0x0/0x4d returned 0 after 41 msecs
+initcall e100_init_module+0x0/0x4d returned 0 after 64 msecs
calling net_olddevs_init+0x0/0x81
initcall net_olddevs_init+0x0/0x81 returned 0 after 0 msecs
calling init_netconsole+0x0/0x185
@@ -717,16 +870,26 @@
netconsole: device eth0 not up yet, forcing it
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
-Clocksource tsc unstable (delta = -499807911 ns)
+Clocksource tsc unstable (delta = -435377680 ns)
console [netcon0] enabled
netconsole: network logging started
-initcall init_netconsole+0x0/0x185 returned 0 after 5702 msecs
+initcall init_netconsole+0x0/0x185 returned 0 after 6403 msecs
calling init_sd+0x0/0xdf
Driver 'sd' needs updating - please use bus_type methods
initcall init_sd+0x0/0xdf returned 0 after 3 msecs
calling piix_init+0x0/0x27
ata_piix 0000:00:1f.1: version 2.12
ata_piix 0000:00:1f.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18
+ __request_region: conflict: (0000:00:1f.1) [1f0, 1f7], res: (ata_piix) [1f0, 1f7]
+ __request_region: good with request direct parent: (0000:00:1f.1) [1f0, 1f7], res: (ata_piix) [1f0, 1f7]
+ __request_region: conflict: (0000:00:1f.1) [3f6, 3f6], res: (ata_piix) [3f6, 3f6]
+ __request_region: good with request direct parent: (0000:00:1f.1) [3f6, 3f6], res: (ata_piix) [3f6, 3f6]
+ __request_region: conflict: (0000:00:1f.1) [170, 177], res: (ata_piix) [170, 177]
+ __request_region: good with request direct parent: (0000:00:1f.1) [170, 177], res: (ata_piix) [170, 177]
+ __request_region: conflict: (0000:00:1f.1) [376, 376], res: (ata_piix) [376, 376]
+ __request_region: good with request direct parent: (0000:00:1f.1) [376, 376], res: (ata_piix) [376, 376]
+ __request_region: conflict: (0000:00:1f.1) [1810, 181f], res: (ata_piix) [1810, 181f]
+ __request_region: good with request direct parent: (0000:00:1f.1) [1810, 181f], res: (ata_piix) [1810, 181f]
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi0 : ata_piix
scsi1 : ata_piix
@@ -738,6 +901,16 @@
scsi 0:0:0:0: CD-ROM MATSHITA UJ-832D 1.02 PQ: 0 ANSI: 5
ata_piix 0000:00:1f.2: PCI INT B -> GSI 18 (level, low) -> IRQ 18
ata_piix 0000:00:1f.2: MAP [ P0 P2 -- -- ]
+ __request_region: conflict: (0000:00:1f.2) [18c8, 18cf], res: (ata_piix) [18c8, 18cf]
+ __request_region: good with request direct parent: (0000:00:1f.2) [18c8, 18cf], res: (ata_piix) [18c8, 18cf]
+ __request_region: conflict: (0000:00:1f.2) [18c0, 18c3], res: (ata_piix) [18c0, 18c3]
+ __request_region: good with request direct parent: (0000:00:1f.2) [18c0, 18c3], res: (ata_piix) [18c0, 18c3]
+ __request_region: conflict: (0000:00:1f.2) [18a8, 18af], res: (ata_piix) [18a8, 18af]
+ __request_region: good with request direct parent: (0000:00:1f.2) [18a8, 18af], res: (ata_piix) [18a8, 18af]
+ __request_region: conflict: (0000:00:1f.2) [180c, 180f], res: (ata_piix) [180c, 180f]
+ __request_region: good with request direct parent: (0000:00:1f.2) [180c, 180f], res: (ata_piix) [180c, 180f]
+ __request_region: conflict: (0000:00:1f.2) [18b0, 18bf], res: (ata_piix) [18b0, 18bf]
+ __request_region: good with request direct parent: (0000:00:1f.2) [18b0, 18bf], res: (ata_piix) [18b0, 18bf]
ata_piix 0000:00:1f.2: setting latency timer to 64
scsi2 : ata_piix
scsi3 : ata_piix
@@ -757,10 +930,13 @@
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 < sda5 sda6 >
sd 2:0:0:0: [sda] Attached SCSI disk
-initcall piix_init+0x0/0x27 returned 0 after 1190 msecs
+initcall piix_init+0x0/0x27 returned 0 after 1274 msecs
calling nonstatic_sysfs_init+0x0/0xf
initcall nonstatic_sysfs_init+0x0/0xf returned 0 after 0 msecs
calling yenta_socket_init+0x0/0x16
+ __request_region: conflict: (PCI Bus 0000:06) [b0100000, b01fffff], res: (yenta_socket) [b0108000, b0108fff]
+ __request_region: conflict: (0000:06:05.0) [b0108000, b0108fff], res: (yenta_socket) [b0108000, b0108fff]
+ __request_region: good with request direct parent: (0000:06:05.0) [b0108000, b0108fff], res: (yenta_socket) [b0108000, b0108fff]
Yenta: CardBus bridge found at 0000:06:05.0 [104d:818f]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
@@ -878,7 +1055,9 @@
calling memmap_init+0x0/0x8a
initcall memmap_init+0x0/0x8a returned 0 after 0 msecs
calling pci_mmcfg_late_insert_resources+0x0/0x41
-initcall pci_mmcfg_late_insert_resources+0x0/0x41 returned 0 after 0 msecs
+ insert_resource: first: (reserved) [e0000000, f0005fff], new: (PCI MMCONFIG 0) [e0000000, efffffff]
+ insert_resource: good with request direct parent: (reserved) [e0000000, f0005fff], new: (PCI MMCONFIG 0) [e0000000, efffffff]
+initcall pci_mmcfg_late_insert_resources+0x0/0x41 returned 0 after 5 msecs
calling tcp_congestion_default+0x0/0xf
initcall tcp_congestion_default+0x0/0xf returned 0 after 0 msecs
Freeing unused kernel memory: 228k freed
-ACPI: Power Button (CM) [PWRB]
-initcall acpi_button_init+0x0/0x51 [button] returned 0 after 114 msecs
-initcall i2c_i801_init+0x0/0x19 [i2c_i801] returned 0 after 32 msecs
+ __request_region: conflict: (0000:00:1f.3) [18e0, 18ff], res: (i801_smbus) [18e0, 18ff]
+ __request_region: good with request direct parent: (0000:00:1f.3) [18e0, 18ff], res: (i801_smbus) [18e0, 18ff]
+initcall i2c_i801_init+0x0/0x19 [i2c_i801] returned 0 after 25 msecs
calling ieee80211_crypto_init+0x0/0xf [ieee80211_crypt]
ieee80211_crypt: registered algorithm 'NULL'
-ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
-firmware: requesting ipw2200-bss.fw
+ __request_region: conflict: (PCI Bus 0000:06) [b0100000, b01fffff], res: (ipw2200) [b0107000, b0107fff]
+ __request_region: conflict: (0000:06:0b.0) [b0107000, b0107fff], res: (ipw2200) [b0107000, b0107fff]
+ __request_region: good with request direct parent: (0000:06:0b.0) [b0107000, b0107fff], res: (ipw2200) [b0107000, b0107fff]
calling alsa_pcm_oss_init+0x0/0x72 [snd_pcm_oss]
initcall alsa_pcm_oss_init+0x0/0x72 [snd_pcm_oss] returned 0 after 0 msecs
calling alsa_seq_device_init+0x0/0x51 [snd_seq_device]
initcall alsa_seq_device_init+0x0/0x51 [snd_seq_device] returned 0 after 0 msecs
calling alsa_card_azx_init+0x0/0x19 [snd_hda_intel]
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
+ __request_region: conflict: (0000:00:1b.0) [b0000000, b0003fff], res: (ICH HD audio) [b0000000, b0003fff]
+ __request_region: good with request direct parent: (0000:00:1b.0) [b0000000, b0003fff], res: (ICH HD audio) [b0000000, b0003fff]
HDA Intel 0000:00:1b.0: setting latency timer to 64
calling joydev_init+0x0/0xf [joydev]
initcall joydev_init+0x0/0xf [joydev] returned 0 after 0 msecs
calling init_sg+0x0/0x139 [sg]
+initcall alsa_card_azx_init+0x0/0x19 [snd_hda_intel] returned 0 after 2960 msecs
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+ __request_region: conflict: (0000:00:1d.0) [1820, 183f], res: (uhci_hcd) [1820, 183f]
+ __request_region: good with request direct parent: (0000:00:1d.0) [1820, 183f], res: (uhci_hcd) [1820, 183f]
+initcall alsa_seq_oss_init+0x0/0x149 [snd_seq_oss] returned 0 after 3189 msecs
+initcall ipw_init+0x0/0x71 [ipw2200] returned 0 after 3585 msecs
uhci_hcd 0000:00:1d.0: setting latency timer to 64
hub 1-0:1.0: 2 ports detected
ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 23 (level, low) -> IRQ 23
+ __request_region: conflict: (0000:00:1d.7) [b0004000, b00043ff], res: (ehci_hcd) [b0004000, b00043ff]
+ __request_region: good with request direct parent: (0000:00:1d.7) [b0004000, b00043ff], res: (ehci_hcd) [b0004000, b00043ff]
ehci_hcd 0000:00:1d.7: setting latency timer to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
@@ -1047,6 +1237,8 @@
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 8 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
+ __request_region: conflict: (0000:00:1d.1) [1840, 185f], res: (uhci_hcd) [1840, 185f]
+ __request_region: good with request direct parent: (0000:00:1d.1) [1840, 185f], res: (uhci_hcd) [1840, 185f]
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
@@ -1055,34 +1247,41 @@
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ohci1394 0000:06:05.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+ __request_region: conflict: (PCI Bus 0000:06) [b0100000, b01fffff], res: (ohci1394) [b0104000, b01047ff]
+ __request_region: conflict: (0000:06:05.2) [b0104000, b01047ff], res: (ohci1394) [b0104000, b01047ff]
+ __request_region: good with request direct parent: (0000:06:05.2) [b0104000, b01047ff], res: (ohci1394) [b0104000, b01047ff]
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 21 (level, low) -> IRQ 21
+ __request_region: conflict: (0000:00:1d.2) [1860, 187f], res: (uhci_hcd) [1860, 187f]
+ __request_region: good with request direct parent: (0000:00:1d.2) [1860, 187f], res: (uhci_hcd) [1860, 187f]
uhci_hcd 0000:00:1d.2: setting latency timer to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
+initcall ehci_hcd_init+0x0/0x19 [ehci_hcd] returned 0 after 1921 msecs
+initcall ohci1394_init+0x0/0x19 [ohci1394] returned 0 after 1764 msecs
uhci_hcd 0000:00:1d.3: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+ __request_region: conflict: (0000:00:1d.3) [1880, 189f], res: (uhci_hcd) [1880, 189f]
+ __request_region: good with request direct parent: (0000:00:1d.3) [1880, 189f], res: (uhci_hcd) [1880, 189f]
+usb 3-1: configuration #1 chosen from 1 choice
uhci_hcd 0000:00:1d.3: setting latency timer to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 17, io base 0x00001880
+input: Microsoft Microsoft Wireless Optical Mouse_ 1.00 as /class/input/input8
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
-usb 3-1: configuration #1 chosen from 1 choice
-initcall uhci_hcd_init+0x0/0x94 [uhci_hcd] returned 0 after 1982 msecs
-input: Microsoft Microsoft Wireless Optical Mouse_ 1.00 as /class/input/input8
input: USB HID v1.11 Mouse [Microsoft Microsoft Wireless Optical Mouse_ 1.00] on usb-0000:00:1d.1-1
+initcall uhci_hcd_init+0x0/0x94 [uhci_hcd] returned 0 after 2323 msecs
+ieee1394: Host added: ID:BUS[0-00:1023] GUID[0800460300efc55d]
calling nvram_init+0x0/0x75 [nvram]
Non-volatile memory driver v1.2
-initcall nvram_init+0x0/0x75 [nvram] returned 0 after 4 msecs
-ieee1394: Host added: ID:BUS[0-00:1023] GUID[0800460300efc55d]
+initcall nvram_init+0x0/0x75 [nvram] returned 0 after 8 msecs
calling asus_acpi_init+0x0/0xe2 [asus_acpi]
initcall asus_acpi_init+0x0/0xe2 [asus_acpi] returned -19 after 0 msecs
calling toshiba_acpi_init+0x0/0x156 [toshiba_acpi]
@@ -1108,7 +1307,7 @@
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
-initcall nf_conntrack_standalone_init+0x0/0xbd [nf_conntrack] returned 0 after 25 msecs
+initcall nf_conntrack_standalone_init+0x0/0xbd [nf_conntrack] returned 0 after 23 msecs
calling state_mt_init+0x0/0x14 [xt_state]
initcall state_mt_init+0x0/0x14 [xt_state] returned 0 after 0 msecs
calling nf_conntrack_l3proto_ipv4_init+0x0/0x118 [nf_conntrack_ipv4]
@@ -1132,36 +1331,41 @@
calling l2cap_init+0x0/0xbc [l2cap]
Bluetooth: L2CAP ver 2.10
Bluetooth: L2CAP socket layer initialized
-initcall l2cap_init+0x0/0xbc [l2cap] returned 0 after 9 msecs
+initcall l2cap_init+0x0/0xbc [l2cap] returned 0 after 10 msecs
calling hidp_init+0x0/0x1e [hidp]
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
-initcall hidp_init+0x0/0x1e [hidp] returned 0 after 4 msecs
+initcall hidp_init+0x0/0x1e [hidp] returned 0 after 5 msecs
calling init_autofs4_fs+0x0/0xf [autofs4]
initcall init_autofs4_fs+0x0/0xf [autofs4] returned 0 after 0 msecs
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
calling inet6_init+0x0/0x2f8 [ipv6]
NET: Registered protocol family 10
-initcall inet6_init+0x0/0x2f8 [ipv6] returned 0 after 30 msecs
+initcall inet6_init+0x0/0x2f8 [ipv6] returned 0 after 31 msecs
eth0: no IPv6 routers present
calling sonypi_init+0x0/0x93 [sonypi]
sonypi: Sony Programmable I/O Controller Driver v1.26.
sonypi: please try the sony-laptop module instead and report failures, see also http://www.linux.it/~malattia/wiki/index.php/Sony_drivers
+ __request_region: conflict: (Sony Programable I/O Device) [1080, 109f], res: (Sony Programable I/O Device Check) [1080, 109f]
+busy flag
sonypi: ioport 0x1080 busy, using sony-laptop? if not use check_ioport=0
sonypi: failed to request ioports
sonypi: probe of sonypi failed with error -16
-initcall sonypi_init+0x0/0x93 [sonypi] returned 0 after 63 msecs
+initcall sonypi_init+0x0/0x93 [sonypi] returned 0 after 71 msecs
calling ipw_init+0x0/0x71 [ipw2200]
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2k
ipw2200: Copyright(c) 2003-2006 Intel Corporation
ipw2200 0000:06:0b.0: power state changed by ACPI to D0
ipw2200 0000:06:0b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+ __request_region: conflict: (PCI Bus 0000:06) [b0100000, b01fffff], res: (ipw2200) [b0107000, b0107fff]
+ __request_region: conflict: (0000:06:0b.0) [b0107000, b0107fff], res: (ipw2200) [b0107000, b0107fff]
+ __request_region: good with request direct parent: (0000:06:0b.0) [b0107000, b0107fff], res: (ipw2200) [b0107000, b0107fff]
ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
firmware: requesting ipw2200-bss.fw
ipw2200: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
ipw2200: Detected geography ZZA (11 802.11bg channels, 13 802.11a channels)
-initcall ipw_init+0x0/0x71 [ipw2200] returned 0 after 240 msecs
-ipw2200: Failed to send WEP_KEY: Command timed out.
-ipw2200: Failed to send WEP_KEY: Command timed out.
+initcall ipw_init+0x0/0x71 [ipw2200] returned 0 after 236 msecs
+ipw2200: Failed to send WEP_KEY: Aborted due to RF kill switch.
ADDRCONF(NETDEV_UP): eth1: link is not ready
ipw2200: Failed to send WEP_KEY: Command timed out.
+ipw2200: Failed to send WEP_KEY: Command timed out.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 5:33 ` Andrew Morton
2008-09-04 7:14 ` Yinghai Lu
@ 2008-09-04 8:02 ` Linus Torvalds
2008-09-04 8:25 ` Andrew Morton
1 sibling, 1 reply; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 8:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu
On Wed, 3 Sep 2008, Andrew Morton wrote:
> On Wed, 3 Sep 2008 22:21:54 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > Can you apply this patch, just to see if it fixes things.
>
> Below..
>
> > And do you know when this started happening? It shouldn't have been all
> > that recent. Maybe you haven't tried your Vaio in a while?
>
> Yes, the Vaio had a vacation in New York. Last kernel it booted was
> 2.6.26-rc8-mm1.
>
> --- x 2008-09-03 21:38:24.000000000 -0700
> +++ y 2008-09-03 22:29:04.000000000 -0700
> ...
> @@ -503,15 +503,15 @@
> calling init_acpi_pm_clocksource+0x0/0x14a
> initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> calling pcibios_assign_resources+0x0/0x70
> -pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
Ok, it fixed that particular thing, and now the mem windows look fine:
> pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> pci 0000:06:05.0: IO window: 0x002400-0x0024ff
> pci 0000:06:05.0: IO window: 0x002800-0x0028ff
> -pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
> +pci 0000:06:05.0: PREFETCH window: 0x50000000-0x53ffffff
> +pci 0000:06:05.0: MEM window: 0x58000000-0x5bffffff
so it fixed _one_ issue.
This also then changes the parent bus bridge:
> pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
> pci 0000:00:1e.0: IO window: 0x2000-0x2fff
> pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
> -pci 0000:00:1e.0: PREFETCH window: disabled
> +pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x00000053ffffff
ie it has now allocated a prefetch window in the parent PCI bridge too
in order to fit that cardbus bridge in.
So this all looks ok. I'd be happier if you also actually had some actual
_device_ in the Cardbus slot and reported that that works, but the patch
clearly
- fixes a very bogus alignment calculation
- actually fixes a Cardbus setup issue for you.
so I'll commit it.
> also...
>
> calling yenta_socket_init+0x0/0x16
> yenta_cardbus 0000:06:05.0: CardBus bridge found [104d:818f]
> -yenta_cardbus 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> -yenta_cardbus 0000:06:05.0: IO window: 0x002400-0x0024ff
> -yenta_cardbus 0000:06:05.0: IO window: 0x002800-0x0028ff
> -yenta_cardbus 0000:06:05.0: PREFETCH window: 0x50400000-0x507fffff
> -yenta_cardbus 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
these went away, because yenta_allocate_resources() will not try to
reprogram the controller if it's already been fully set up. So because
yenta_alloc_resources() is happy with the resource setup and leaves it
alone, there's no more noise about it.
So I would say that the PCI resource issue is fixed.
[ Side note: I actually suspect that your cardbus slot actually worked
fine _despite_ the problems, because
(a) the whole yenta_allocate_resources() -> pci_setup_cardbus() sequence
did end up setting things up correctly int he end, even if the
prefetchable memory resource ended up being in a non-prefetchable
area
(b) Very few cardbus cards would have any prefetchable resources, much
less care about the theoretical performance difference even if they
did.
but that allocation issue was still a bug ]
And you seem to have found your non-console problem separately.
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH] hid: fix gyration build error
2008-09-04 6:52 ` Jiri Slaby
@ 2008-09-04 8:06 ` Jiri Kosina
0 siblings, 0 replies; 53+ messages in thread
From: Jiri Kosina @ 2008-09-04 8:06 UTC (permalink / raw)
To: Jiri Slaby, Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, akpm
On Thu, 4 Sep 2008, Jiri Slaby wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > Fix config symbol name in ifdef to fix build error:
> > ERROR: "hid_compat_gyration" [drivers/hid/hid-dummy.ko] undefined!
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> > cc: Jiri Kosina <jkosina@suse.cz>
> Acked-by: Jiri Slaby <jirislaby@gmail.com>
Applied, thanks for catching it.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:14 ` Yinghai Lu
2008-09-04 8:00 ` Andrew Morton
@ 2008-09-04 8:23 ` Linus Torvalds
1 sibling, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 8:23 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Andrew Morton, Stephen Rothwell, linux-next, LKML
On Thu, 4 Sep 2008, Yinghai Lu wrote:
> >
> > --- x 2008-09-03 21:38:24.000000000 -0700
> > +++ y 2008-09-03 22:29:04.000000000 -0700
> > ...
> > @@ -503,15 +503,15 @@
> > calling init_acpi_pm_clocksource+0x0/0x14a
> > initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> > calling pcibios_assign_resources+0x0/0x70
> > -pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
> > pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> > pci 0000:06:05.0: IO window: 0x002400-0x0024ff
> > pci 0000:06:05.0: IO window: 0x002800-0x0028ff
> > -pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
> > +pci 0000:06:05.0: PREFETCH window: 0x50000000-0x53ffffff
> > +pci 0000:06:05.0: MEM window: 0x58000000-0x5bffffff
> > pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
> > pci 0000:00:1e.0: IO window: 0x2000-0x2fff
> > pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
> > -pci 0000:00:1e.0: PREFETCH window: disabled
> > +pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x00000053ffffff
> > pci 0000:00:1e.0: setting latency timer to 64
> > pci 0000:06:05.0: power state changed by ACPI to D0
>
> 06:05.0 is under 00:1e.0
Right. This is the depth-first bus assignment, so what happens is that
pci_assign_unassigned_resources() does:
/* Depth first, calculate sizes and alignments of all
subordinate buses. */
list_for_each_entry(bus, &pci_root_buses, node) {
pci_bus_size_bridges(bus);
}
where pci_bus_size_bridges() does depth-first (and _has_ to, of course,
since it needs to look at the inner bridges in order to be able to size
the outer ones!)
And there it will now successfully see that BAR 9 that used to get
ignored, so now it sizes the PCI bridge that leads _to_ the Cardbus bridge
with that in mind. So that is why the "BAR 9 too large" message has gone
away, but that is all that got printed out at the resource _sizing_ stage.
And then, after all the sizing has been done, the odd ordering of the
printout is because we next do:
/* Depth last, allocate resources and update the hardware. */
list_for_each_entry(bus, &pci_root_buses, node) {
pci_bus_assign_resources(bus);
pci_enable_bridges(bus);
}
and that "Depth last" comment is a bit mis-leading.
It is true that "pci_bus_assign_resources()" will make the actual call to
"pbus_assign_resources_sorted()" depth-last, but if you look at how it
then actually writes those assigned resources to the actual bridge
devices, it will do those "pci_setup_bridge/cardbus()" calls depth-first:
if you look at pci_bus_assign_resources(), you'll see that it does the
recursive call for the subordinate bus _before_ it sets up the upper
bridge.
And since the _printout_ comes when the final setup is done, that means
that the Cardbus bridge (that is deeper in the resource chain) will print
out first. So even though the resource was _allocated_ depth-last, it is
written out depth-first!
> wonder if some pci code change cause that.... doesn't get pref mem assigned.
>
> can you apply attached patches to get more dump?
It all works fine, and makes sense (well, except for the printout order,
which is a bit non-obvious, but it all boils down to us wanting to have
all the inner bridges set up correctly before we "enable" them through the
outer bridge mapping, so that depth-first makes sense, I think).
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:02 ` Linus Torvalds
@ 2008-09-04 8:25 ` Andrew Morton
2008-09-04 8:37 ` Andrew Morton
2008-09-04 8:50 ` Linus Torvalds
0 siblings, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 8:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu
On Thu, 4 Sep 2008 01:02:10 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So this all looks ok. I'd be happier if you also actually had some actual
> _device_ in the Cardbus slot and reported that that works, but the patch
> clearly
<rummages for ten minutes>
<found it!>
<plugs it in>
cs: pcmcia_socket0: unable to apply power.
pccard: CardBus card inserted into slot 0
pci 0000:07:00.0: supports D1
pci 0000:07:00.0: supports D2
pci 0000:07:00.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:07:00.0: PME# disabled
sony:/home/akpm> lspci -s07:00
07:00.0 Ethernet controller: 3Com Corporation 3cCFE575CT CardBus [Cyclone] (rev 10)
seems OK.
<applies the patch, enables 3c59x.ko>
<reboots, plugs in card>
cs: pcmcia_socket0: unable to apply power.
pccard: CardBus card inserted into slot 0
pci 0000:07:00.0: supports D1
pci 0000:07:00.0: supports D2
pci 0000:07:00.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:07:00.0: PME# disabled
calling vortex_init+0x0/0x9e [3c59x]
3c59x 0000:07:00.0: enabling device (0000 -> 0003)
3c59x 0000:07:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
3c59x: Donald Becker and others.
0000:07:00.0: 3Com PCI 3CCFE575CT Tornado CardBus at f8cb2000.
3c59x 0000:07:00.0: setting latency timer to 64
initcall vortex_init+0x0/0x9e [3c59x] returned 0 after 36 msecs
can't complain about that, apart from the apparently-bogus "unable to
apply power".
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:25 ` Andrew Morton
@ 2008-09-04 8:37 ` Andrew Morton
2008-09-04 9:03 ` Linus Torvalds
2008-09-04 8:50 ` Linus Torvalds
1 sibling, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 8:37 UTC (permalink / raw)
To: Linus Torvalds, Stephen Rothwell, linux-next, LKML, Yinghai Lu
Cc: Jesse Barnes
On Thu, 4 Sep 2008 01:25:44 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> can't complain about that, apart from the apparently-bogus "unable to
> apply power".
ooh look, I fixed something:
--- a/drivers/pcmcia/cs.c~a
+++ a/drivers/pcmcia/cs.c
@@ -477,6 +477,8 @@ static int socket_setup(struct pcmcia_so
*/
msleep(vcc_settle * 10);
+ msleep(100);
+
skt->ops->get_status(skt, &status);
if (!(status & SS_POWERON)) {
cs_err(skt, "unable to apply power.\n");
_
we seem not to be giving that card enough settling time. Or is it
a characteristic of the controller?
It's a module option, but google(linux "unable to apply power") gets
859 hits. Maybe the default is too short..
btw, do we really need to spew all this?
pccard: card ejected from slot 0
3c59x 0000:07:00.0: restoring config space at offset 0xf (was 0xffffffff, writing 0x50a0115)
3c59x 0000:07:00.0: restoring config space at offset 0xe (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0xd (was 0xffffffff, writing 0x50)
3c59x 0000:07:00.0: restoring config space at offset 0xc (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0xb (was 0xffffffff, writing 0x5c5710b7)
3c59x 0000:07:00.0: restoring config space at offset 0xa (was 0xffffffff, writing 0x90)
3c59x 0000:07:00.0: restoring config space at offset 0x9 (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0x8 (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0x7 (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0x6 (was 0xffffffff, writing 0x58000080)
3c59x 0000:07:00.0: restoring config space at offset 0x5 (was 0xffffffff, writing 0x58000000)
3c59x 0000:07:00.0: restoring config space at offset 0x4 (was 0xffffffff, writing 0x2401)
3c59x 0000:07:00.0: restoring config space at offset 0x3 (was 0xffffffff, writing 0x4000)
3c59x 0000:07:00.0: restoring config space at offset 0x2 (was 0xffffffff, writing 0x2000010)
3c59x 0000:07:00.0: restoring config space at offset 0x1 (was 0xffffffff, writing 0x2100007)
3c59x 0000:07:00.0: restoring config space at offset 0x0 (was 0xffffffff, writing 0x525710b7)
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:25 ` Andrew Morton
2008-09-04 8:37 ` Andrew Morton
@ 2008-09-04 8:50 ` Linus Torvalds
2008-09-04 8:57 ` Andrew Morton
2008-09-09 4:39 ` Jesse Barnes
1 sibling, 2 replies; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 8:50 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes
On Thu, 4 Sep 2008, Andrew Morton wrote:
>
> <plugs it in>
>
> cs: pcmcia_socket0: unable to apply power.
> pccard: CardBus card inserted into slot 0
> pci 0000:07:00.0: supports D1
> pci 0000:07:00.0: supports D2
> pci 0000:07:00.0: PME# supported from D1 D2 D3hot D3cold
> pci 0000:07:00.0: PME# disabled
>
> sony:/home/akpm> lspci -s07:00
> 07:00.0 Ethernet controller: 3Com Corporation 3cCFE575CT CardBus [Cyclone] (rev 10)
Ok, the PCI resource side definitely works.
I've committed the fix as follows.. (the explanation is about three times
the size, but whatever ;)
As to that "unable to apply power" thing, that's a separate issue.. And
in fact one that probably doesn't even matter to a CardBus card, since
cardbus doesn't care about the insane CS state machines anyway.
Anyway, Ivan and Jesse cc'd for the patch, but I committed it, since I
was involved in causing the bug in the first place.
Linus
---
commit 5f17cfce5776c566d64430f543a289e5cfa4538b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Sep 4 01:33:59 2008 -0700
PCI: fix pbus_size_mem() resource alignment for CardBus controllers
Commit 884525655d07fdee9245716b998ecdc45cdd8007 ("PCI: clean up resource
alignment management") changed the resource handling to mark how a
resource was aligned on a per-resource basis.
Thus, instead of looking at the resource number to determine whether it
was a bridge resource or a regular resource (they have different
alignment rules), we should just ask the resource for its alignment
directly.
The reason this broke only cardbus resources was that for the other
types of resources, the old way of deciding alignment actually still
happened to work. But CardBus bridge resources had been changed by
commit 934b7024f0ed29003c95cef447d92737ab86dc4f ("Fix cardbus resource
allocation") to look more like regular resources than PCI bridge
resources from an alignment handling standpoint.
Reported-and-tested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
drivers/pci/setup-bus.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 82634a2..1aad599 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -352,11 +352,12 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, unsigned long
continue;
r_size = r->end - r->start + 1;
/* For bridges size != alignment */
- align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
+ align = resource_alignment(r);
order = __ffs(align) - 20;
if (order > 11) {
- dev_warn(&dev->dev, "BAR %d too large: "
+ dev_warn(&dev->dev, "BAR %d bad alignment %llx: "
"%#016llx-%#016llx\n", i,
+ (unsigned long long)align,
(unsigned long long)r->start,
(unsigned long long)r->end);
r->flags = 0;
^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:50 ` Linus Torvalds
@ 2008-09-04 8:57 ` Andrew Morton
2008-09-04 9:07 ` Linus Torvalds
2008-09-09 4:39 ` Jesse Barnes
1 sibling, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 8:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes
On Thu, 4 Sep 2008 01:50:58 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> commit 5f17cfce5776c566d64430f543a289e5cfa4538b
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Thu Sep 4 01:33:59 2008 -0700
>
> PCI: fix pbus_size_mem() resource alignment for CardBus controllers
>
> Commit 884525655d07fdee9245716b998ecdc45cdd8007 ("PCI: clean up resource
> alignment management") changed the resource handling to mark how a
> resource was aligned on a per-resource basis.
>
> Thus, instead of looking at the resource number to determine whether it
> was a bridge resource or a regular resource (they have different
> alignment rules), we should just ask the resource for its alignment
> directly.
>
> The reason this broke only cardbus resources was that for the other
> types of resources, the old way of deciding alignment actually still
> happened to work. But CardBus bridge resources had been changed by
> commit 934b7024f0ed29003c95cef447d92737ab86dc4f ("Fix cardbus resource
> allocation") to look more like regular resources than PCI bridge
> resources from an alignment handling standpoint.
>
> Reported-and-tested-by: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> drivers/pci/setup-bus.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 82634a2..1aad599 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -352,11 +352,12 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, unsigned long
> continue;
> r_size = r->end - r->start + 1;
> /* For bridges size != alignment */
> - align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
> + align = resource_alignment(r);
> order = __ffs(align) - 20;
> if (order > 11) {
> - dev_warn(&dev->dev, "BAR %d too large: "
> + dev_warn(&dev->dev, "BAR %d bad alignment %llx: "
> "%#016llx-%#016llx\n", i,
> + (unsigned long long)align,
> (unsigned long long)r->start,
> (unsigned long long)r->end);
> r->flags = 0;
Is this worth backporting into 2.6.26.x?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:37 ` Andrew Morton
@ 2008-09-04 9:03 ` Linus Torvalds
0 siblings, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 9:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Jesse Barnes
On Thu, 4 Sep 2008, Andrew Morton wrote:
>
> ooh look, I fixed something:
>
> --- a/drivers/pcmcia/cs.c~a
> +++ a/drivers/pcmcia/cs.c
> @@ -477,6 +477,8 @@ static int socket_setup(struct pcmcia_so
> */
> msleep(vcc_settle * 10);
>
> + msleep(100);
> +
Heh. I'm hoping that it would help to just change vcc_settle to 50
instead?
> skt->ops->get_status(skt, &status);
> if (!(status & SS_POWERON)) {
> cs_err(skt, "unable to apply power.\n");
> _
>
> we seem not to be giving that card enough settling time. Or is it
> a characteristic of the controller?
No, I think it's mainly the card.
> It's a module option, but google(linux "unable to apply power") gets
> 859 hits. Maybe the default is too short..
I certainly don't think it would be wrong to change it to a longer
timeout. Although I also suspect that we should in that case try to exit
early too, ie change it to something like
for (i = 0; i < vcc_settle; i++) {
msleep(10);
skt->ops->get_status(skt, &status);
if (status & SS_POWERON)
break;
}
or similar. But if changing it to 50 fixes it for you, that's probably a
good minimal change for now.
> btw, do we really need to spew all this?
>
> pccard: card ejected from slot 0
> 3c59x 0000:07:00.0: restoring config space at offset 0xf (was 0xffffffff, writing 0x50a0115)
> 3c59x 0000:07:00.0: restoring config space at offset 0xe (was 0xffffffff, writing 0x0)
...
No.
Although it's really a KERN_DEBUG(), so most people shouldn't even notice.
I do wonder why somebody does pci_restore_state() when the card is
ejected..
Oh. It's literally drivers/net/3c59x.c: vortex_remove_one(). So it's not
the PCI or Cardbus layer, it's the driver itself doing odd things. I don't
think it's worth worrying about. It's trying to restore the state and
disable the device that was unplugged and no longer exists ;)
(Which can definitely be a useful thing if the remove_one is done because
of some user-initiated driver removal. So I do understand why the driver
has that code, it just doesn't make sense when the removal is due to the
hardware itself going away).
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:57 ` Andrew Morton
@ 2008-09-04 9:07 ` Linus Torvalds
2008-09-04 17:45 ` Andrew Morton
0 siblings, 1 reply; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 9:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes
On Thu, 4 Sep 2008, Andrew Morton wrote:
> >
> > commit 5f17cfce5776c566d64430f543a289e5cfa4538b
> >
> > PCI: fix pbus_size_mem() resource alignment for CardBus controllers
>
> Is this worth backporting into 2.6.26.x?
It's certainly at least *potentially* -stable material, but because I
suspect that the whole yenta_allocate_resources() -> pci_setup_cardbus()
fallback code will end up resulting in a working setup, it may not be
worth it. At least not until we've heard from more people..
Can you check whether your vortex cardbus thing _works_ even without the
fix?
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:15 ` Andrew Morton
2008-09-04 7:48 ` Stephen Rothwell
@ 2008-09-04 9:19 ` Alan Cox
2008-09-04 9:21 ` Alan Cox
` (2 subsequent siblings)
4 siblings, 0 replies; 53+ messages in thread
From: Alan Cox @ 2008-09-04 9:19 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Linus Torvalds,
David Woodhouse
On Thu, 4 Sep 2008 00:15:58 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 3 Sep 2008 23:01:29 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > I'll see if I cen reproduce the bug I'm
> > actually tring to find with E100=n.
>
> OK, this regression[*] bisects down to
Your first serious looking error:
"Module 'acpi' failed to be added to sysfs, error number -17
The system will be unstable now."
is not even connected to this area of the code.
and I can't find any meaningful description of your regression to attempt
to duplicate it on a cleaner tree without it already saying "I'm unstable"
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:15 ` Andrew Morton
2008-09-04 7:48 ` Stephen Rothwell
2008-09-04 9:19 ` Alan Cox
@ 2008-09-04 9:21 ` Alan Cox
2008-09-04 11:01 ` Alan Cox
2008-09-04 14:35 ` Alan Cox
4 siblings, 0 replies; 53+ messages in thread
From: Alan Cox @ 2008-09-04 9:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Linus Torvalds,
David Woodhouse
> [*] symptoms: there are no login prompts appearing on the VT consoles.
> sshd works OK (will it did, but I had to disable the net driver due to
> networking bisect breakage).
What does an strace of the getty tasks show ?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:15 ` Andrew Morton
` (2 preceding siblings ...)
2008-09-04 9:21 ` Alan Cox
@ 2008-09-04 11:01 ` Alan Cox
2008-09-04 14:35 ` Alan Cox
4 siblings, 0 replies; 53+ messages in thread
From: Alan Cox @ 2008-09-04 11:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Linus Torvalds,
David Woodhouse
> I cannot find any of these patches on a mailing list.
I suppose I should post an updated set now and then. I've fixed the stuff
that leaked into the next diff and broke the compile at the bisection
point. Your fixup seems fine however so I don't think it invalidated the
diff.
> I cannot revert tty-kref-get-current-tty and I can't immediately spot
> the bug in it.
Nor me and there is definitely high weirdness going on here. I've gone
back to Linus tree + patches up to tty-kref-get-current-tty and I can get
it to sometimes not make consoles reappear after logout. That seems to be
new as of the -rc5 base tree.
Alan
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 7:15 ` Andrew Morton
` (3 preceding siblings ...)
2008-09-04 11:01 ` Alan Cox
@ 2008-09-04 14:35 ` Alan Cox
4 siblings, 0 replies; 53+ messages in thread
From: Alan Cox @ 2008-09-04 14:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Linus Torvalds,
David Woodhouse
> I cannot revert tty-kref-get-current-tty and I can't immediately spot
> the bug in it.
Nailed it; magic ingredient is SELinux inclusion which then triggers a
leak on a flush unauthorized
diff --git a/drivers/s390/char/fs3270.c b/drivers/s390/char/fs3270.c
index d18e6d2..3ef5425 100644
--- a/drivers/s390/char/fs3270.c
+++ b/drivers/s390/char/fs3270.c
@@ -430,11 +430,12 @@ fs3270_open(struct inode *inode, struct file *filp)
mutex_lock(&tty_mutex);
tty = get_current_tty();
if (!tty || tty->driver->major != IBM_TTY3270_MAJOR) {
- mutex_unlock(&tty_mutex);
+ tty_kref_put(tty);
rc = -ENODEV;
goto out;
}
minor = tty->index + RAW3270_FIRSTMINOR;
+ tty_kref_put(tty);
mutex_unlock(&tty_mutex);
}
/* Check if some other program is already using fullscreen mode. */
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 03fc6a8..c856db8 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2122,6 +2122,7 @@ static inline void flush_unauthorized_files(struct files_struct *files)
mutex_lock(&tty_mutex);
tty = get_current_tty();
+ mutex_unlock(&tty_mutex);
if (tty) {
file_list_lock();
file = list_entry(tty->tty_files.next, typeof(*file), f_u.fu_list);
@@ -2138,8 +2139,8 @@ static inline void flush_unauthorized_files(struct files_struct *files)
}
}
file_list_unlock();
+ tty_kref_put(tty);
}
- mutex_unlock(&tty_mutex);
/* Reset controlling tty. */
if (drop_tty)
no_tty();
^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 9:07 ` Linus Torvalds
@ 2008-09-04 17:45 ` Andrew Morton
2008-09-04 18:05 ` Linus Torvalds
0 siblings, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 17:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes, netdev, Al Viro
On Thu, 4 Sep 2008 02:07:05 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 4 Sep 2008, Andrew Morton wrote:
> > >
> > > commit 5f17cfce5776c566d64430f543a289e5cfa4538b
> > >
> > > PCI: fix pbus_size_mem() resource alignment for CardBus controllers
> >
> > Is this worth backporting into 2.6.26.x?
>
> It's certainly at least *potentially* -stable material, but because I
> suspect that the whole yenta_allocate_resources() -> pci_setup_cardbus()
> fallback code will end up resulting in a working setup, it may not be
> worth it. At least not until we've heard from more people..
>
> Can you check whether your vortex cardbus thing _works_ even without the
> fix?
>
Working on it, but got distracted by a /proc/net bug.
sony:/home/akpm> ifconfig -a
Warning: cannot open /proc/net/dev (Permission denied). Limited output.
Warning: cannot open /proc/net/dev (Permission denied). Limited output.
eth0 Link encap:Ethernet HWaddr 00:01:4A:9F:7C:79
inet addr:192.168.2.10 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Warning: cannot open /proc/net/dev (Permission denied). Limited output.
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
sony:/home/akpm> ls -l /proc/net/dev
ls: /proc/net/dev: Permission denied
sony:/home/akpm> ls -l /proc/net
ls: /proc/net: Permission denied
sony:/home/akpm> ls -ld /proc/net
ls: /proc/net: Permission denied
sony:/home/akpm> ls -l /proc | grep net
?--------- ? ? ? ? ? /proc/net
This is a pull of your tree from yesterday, ending at
commit fbb16e243887332dd5754e48ffe5b963378f3cd2
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Sep 3 00:54:47 2008 +0200
[x86] Fix TSC calibration issues
config: http://userweb.kernel.org/~akpm/config-sony.txt
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 17:45 ` Andrew Morton
@ 2008-09-04 18:05 ` Linus Torvalds
0 siblings, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 18:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes, netdev, Al Viro, Eric W. Biederman, Al Viro
On Thu, 4 Sep 2008, Andrew Morton wrote:
>
> Working on it, but got distracted by a /proc/net bug.
Ok, that's just something odd.
> sony:/home/akpm> ls -l /proc/net/dev
> ls: /proc/net/dev: Permission denied
>
> sony:/home/akpm> ls -l /proc/net
> ls: /proc/net: Permission denied
>
> sony:/home/akpm> ls -ld /proc/net
> ls: /proc/net: Permission denied
>
> sony:/home/akpm> ls -l /proc | grep net
> ?--------- ? ? ? ? ? /proc/net
>
> This is a pull of your tree from yesterday, ending at commit
> fbb16e243887332dd5754e48ffe5b963378f3cd2
There's been various suggested patches by Al/Eric (added to cc) for
/proc/net handling, but none of them have actually even been merged yet.
So I don't think this code has changed in a while.
Al, Eric, ideas?
> config: http://userweb.kernel.org/~akpm/config-sony.txt
> dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
That whole thing should just be a simple symlink:
fs/proc/proc_net.c: proc_symlink("net", NULL, "self/net");
are you sure it's a plain tree of mine, without any of the patches
floating around between Eric/Al?
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
@ 2008-09-04 18:05 ` Linus Torvalds
0 siblings, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 18:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes, netdev, Al Viro, Eric W. Biederman
On Thu, 4 Sep 2008, Andrew Morton wrote:
>
> Working on it, but got distracted by a /proc/net bug.
Ok, that's just something odd.
> sony:/home/akpm> ls -l /proc/net/dev
> ls: /proc/net/dev: Permission denied
>
> sony:/home/akpm> ls -l /proc/net
> ls: /proc/net: Permission denied
>
> sony:/home/akpm> ls -ld /proc/net
> ls: /proc/net: Permission denied
>
> sony:/home/akpm> ls -l /proc | grep net
> ?--------- ? ? ? ? ? /proc/net
>
> This is a pull of your tree from yesterday, ending at commit
> fbb16e243887332dd5754e48ffe5b963378f3cd2
There's been various suggested patches by Al/Eric (added to cc) for
/proc/net handling, but none of them have actually even been merged yet.
So I don't think this code has changed in a while.
Al, Eric, ideas?
> config: http://userweb.kernel.org/~akpm/config-sony.txt
> dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
That whole thing should just be a simple symlink:
fs/proc/proc_net.c: proc_symlink("net", NULL, "self/net");
are you sure it's a plain tree of mine, without any of the patches
floating around between Eric/Al?
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 18:05 ` Linus Torvalds
(?)
@ 2008-09-04 18:34 ` Andrew Morton
2008-09-04 20:31 ` Eric W. Biederman
2008-09-04 22:45 ` Thomas Gleixner
-1 siblings, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 18:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, linux-next, LKML, Yinghai Lu, Ivan Kokshaysky,
Jesse Barnes, netdev, Al Viro, Eric W. Biederman,
David Woodhouse, Sam Ravnborg, john stultz, Thomas Gleixner
On Thu, 4 Sep 2008 11:05:21 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > This is a pull of your tree from yesterday, ending at commit
> > fbb16e243887332dd5754e48ffe5b963378f3cd2
>
> There's been various suggested patches by Al/Eric (added to cc) for
> /proc/net handling, but none of them have actually even been merged yet.
> So I don't think this code has changed in a while.
>
> Al, Eric, ideas?
I don't think I saw it on any other test machines.
This machine runs SELinux. Distro is FC5.
> > config: http://userweb.kernel.org/~akpm/config-sony.txt
> > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
>
> That whole thing should just be a simple symlink:
>
> fs/proc/proc_net.c: proc_symlink("net", NULL, "self/net");
/proc/self/net looks fine.
> are you sure it's a plain tree of mine, without any of the patches
> floating around between Eric/Al?
yup, it's yesterday's mainline.
Found another problem.
The way I install kernels on machine `sony' is:
- Build the kernel on machine `y', in /usr/src/25
- On machine sony, NFS mount y:/usr/src at /mnt/y/usr/src
- On sony, `cd /mnt/y/usr/src/25'
- <copy stuff>
- make modules_install
- depmod -a
IOW, I run the kernel's installation tools on the *target* machine,
within an nfs mount of the *build* machine.
This has worked happily for five or more years. But now:
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw [<options>] <src.HEX> <dst.fw>
-w: wide records (16-bit length)
-s: sort records by address
make[1]: *** [firmware/emi26/loader.fw] Error 1
make: *** [_modinst_post] Error 2
This is because the target machine is i386 and it is trying to execute
an x86_64 binary.
and oh dear, the clockevents code just oopsed.
firmware: requesting ipw2200-bss.fw
ipw2200: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
ipw2200: Detected geography ZZA (11 802.11bg channels, 13 802.11a channels)
initcall ipw_init+0x0/0x71 [ipw2200] returned 0 after 163 msecs
ipw2200: Failed to send WEP_KEY: Aborted due to RF kill switch.
BUG: unable to handle kernel NULL pointer dereference at 00000040
IP: [<c0126e7f>] get_next_timer_interrupt+0xe9/0x1ab
*pde = 00000000
Oops: 0000 [#1] PREEMPT
Modules linked in: ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ieee80211 3c59x snd_pcm ieee80211_crypt sr_mod snd_timer cdrom snd i2c_i801 soundcore snd_page_alloc button i2c_core pcspkr ext3 jbd [last unloaded: ipw2200]
Pid: 0, comm: swapper Not tainted (2.6.27-rc5 #18)
EIP: 0060:[<c0126e7f>] EFLAGS: 00010013 CPU: 0
EIP is at get_next_timer_interrupt+0xe9/0x1ab
EAX: 00000040 EBX: 00000001 ECX: 0000001d EDX: 00000040
ESI: 0000001d EDI: c05bc700 EBP: c0469f1c ESP: c0469ee4
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0468000 task=c04343c0 task.ti=c0468000)
Stack: ffff1cef c013cc1d c05bcf28 00000000 c05bd010 c05bc798 00ffff1d c05bcf28
c05bd128 c05bd328 c05bd528 00000000 b65eb8b3 0000000f c0469f4c c013816f
00000000 b65c1f00 0000000f ffff1cef 00000046 00000096 c04b11c0 00000000
Call Trace:
[<c013cc1d>] ? __lock_acquire+0x671/0x6b7
[<c013816f>] ? tick_nohz_stop_sched_tick+0x13f/0x2ba
[<c0123640>] ? irq_exit+0x6d/0x79
[<c0105c6a>] ? do_IRQ+0x6d/0x7f
[<c0104300>] ? common_interrupt+0x28/0x30
[<c013007b>] ? set_process_cpu_timer+0x94/0xb9
[<c0234743>] ? acpi_processor_idle+0x2a6/0x44b
[<c010256b>] ? cpu_idle+0x5a/0x87
[<c031e2fd>] ? rest_init+0x61/0x63
=======================
Code: 83 e6 3f 89 f1 89 5d d0 8b 45 d0 89 d3 8d 04 c8 89 45 d8 8b 00 eb 14 8b 40 08 bb 01 00 00 00 3b 45 cc 0f 49 45 cc 89 45 cc 89 d0 <8b> 10 0f 18 02 90 3b 45 d8 75 e1 85 db 89 da 74 0c 85 f6 74 04
EIP: [<c0126e7f>] get_next_timer_interrupt+0xe9/0x1ab SS:ESP 0068:c0469ee4
---[ end trace 2cf31fb827f3051f ]---
Kernel panic - not syncing: Attempted to kill the idle task!
BUG: NMI Watchdog detected LOCKUP on CPU0, ip c01f584e, registers:
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 18:34 ` Andrew Morton
@ 2008-09-04 20:31 ` Eric W. Biederman
2008-09-04 20:41 ` Andrew Morton
2008-09-04 22:45 ` Thomas Gleixner
1 sibling, 1 reply; 53+ messages in thread
From: Eric W. Biederman @ 2008-09-04 20:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Stephen Rothwell, linux-next, LKML, Yinghai Lu,
Ivan Kokshaysky, Jesse Barnes, netdev, Al Viro, David Woodhouse,
Sam Ravnborg, john stultz, Thomas Gleixner
Andrew Morton <akpm@linux-foundation.org> writes:
> On Thu, 4 Sep 2008 11:05:21 -0700 (PDT) Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>
>> > This is a pull of your tree from yesterday, ending at commit
>> > fbb16e243887332dd5754e48ffe5b963378f3cd2
>>
>> There's been various suggested patches by Al/Eric (added to cc) for
>> /proc/net handling, but none of them have actually even been merged yet.
>> So I don't think this code has changed in a while.
>>
>> Al, Eric, ideas?
There aren't any issues I know of with normal configurations
and the current proc code.
> I don't think I saw it on any other test machines.
>
> This machine runs SELinux. Distro is FC5.
>> > config: http://userweb.kernel.org/~akpm/config-sony.txt
>> > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
>>
>> That whole thing should just be a simple symlink:
>>
>> fs/proc/proc_net.c: proc_symlink("net", NULL, "self/net");
>
> /proc/self/net looks fine.
>
>> are you sure it's a plain tree of mine, without any of the patches
>> floating around between Eric/Al?
>
> yup, it's yesterday's mainline.
Does the problem happen if you disable selinux?
This feels like a case of selinux being over zealous.
Eric
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 20:31 ` Eric W. Biederman
@ 2008-09-04 20:41 ` Andrew Morton
0 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 20:41 UTC (permalink / raw)
To: Eric W. Biederman
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, dwmw2, sam, johnstul, tglx
On Thu, 04 Sep 2008 13:31:01 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> >> > config: http://userweb.kernel.org/~akpm/config-sony.txt
> >> > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
> >>
> >> That whole thing should just be a simple symlink:
> >>
> >> fs/proc/proc_net.c: proc_symlink("net", NULL, "self/net");
> >
> > /proc/self/net looks fine.
> >
> >> are you sure it's a plain tree of mine, without any of the patches
> >> floating around between Eric/Al?
> >
> > yup, it's yesterday's mainline.
>
> Does the problem happen if you disable selinux?
>
> This feels like a case of selinux being over zealous.
yeah, adding `selinux=0' to the boot command line fixes it.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
@ 2008-09-04 20:41 ` Andrew Morton
0 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 20:41 UTC (permalink / raw)
To: Eric W. Biederman
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, dwmw2, sam, johnstul, tglx
On Thu, 04 Sep 2008 13:31:01 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> >> > config: http://userweb.kernel.org/~akpm/config-sony.txt
> >> > dmesg: http://userweb.kernel.org/~akpm/dmesg-sony-without.txt
> >>
> >> That whole thing should just be a simple symlink:
> >>
> >> fs/proc/proc_net.c: proc_symlink("net", NULL, "self/net");
> >
> > /proc/self/net looks fine.
> >
> >> are you sure it's a plain tree of mine, without any of the patches
> >> floating around between Eric/Al?
> >
> > yup, it's yesterday's mainline.
>
> Does the problem happen if you disable selinux?
>
> This feels like a case of selinux being over zealous.
yeah, adding `selinux=0' to the boot command line fixes it.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 20:41 ` Andrew Morton
(?)
@ 2008-09-04 21:03 ` Eric W. Biederman
2008-09-04 22:22 ` Andrew Morton
-1 siblings, 1 reply; 53+ messages in thread
From: Eric W. Biederman @ 2008-09-04 21:03 UTC (permalink / raw)
To: Andrew Morton
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, dwmw2, sam, johnstul, tglx
Andrew Morton <akpm@linux-foundation.org> writes:
> On Thu, 04 Sep 2008 13:31:01 -0700
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> >> are you sure it's a plain tree of mine, without any of the patches
>> >> floating around between Eric/Al?
>> >
>> > yup, it's yesterday's mainline.
>>
>> Does the problem happen if you disable selinux?
>>
>> This feels like a case of selinux being over zealous.
>
> yeah, adding `selinux=0' to the boot command line fixes it.
The proc generic directory back structure is the same. As requested by
the selinux folks. So I don't expect there is much more we can do on
the /proc side.
When we get the interaction bug between the VFS and /proc/net fixed I wonder
if there will be some more selinux fall out. Something to think about.
Eric
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 21:03 ` Eric W. Biederman
@ 2008-09-04 22:22 ` Andrew Morton
0 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 22:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, dwmw2, sam, johnstul, tglx
On Thu, 04 Sep 2008 14:03:41 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Thu, 04 Sep 2008 13:31:01 -0700
> > ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> >> >> are you sure it's a plain tree of mine, without any of the patches
> >> >> floating around between Eric/Al?
> >> >
> >> > yup, it's yesterday's mainline.
> >>
> >> Does the problem happen if you disable selinux?
> >>
> >> This feels like a case of selinux being over zealous.
> >
> > yeah, adding `selinux=0' to the boot command line fixes it.
>
> The proc generic directory back structure is the same. As requested by
> the selinux folks. So I don't expect there is much more we can do on
> the /proc side.
>
> When we get the interaction bug between the VFS and /proc/net fixed I wonder
> if there will be some more selinux fall out. Something to think about.
fyi, that machine is x86_32-on-FC5. My x86_64-on-FC6 test box is
also running selinux and has the same bug.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
@ 2008-09-04 22:22 ` Andrew Morton
0 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 22:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, dwmw2, sam, johnstul, tglx
On Thu, 04 Sep 2008 14:03:41 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Thu, 04 Sep 2008 13:31:01 -0700
> > ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> >> >> are you sure it's a plain tree of mine, without any of the patches
> >> >> floating around between Eric/Al?
> >> >
> >> > yup, it's yesterday's mainline.
> >>
> >> Does the problem happen if you disable selinux?
> >>
> >> This feels like a case of selinux being over zealous.
> >
> > yeah, adding `selinux=0' to the boot command line fixes it.
>
> The proc generic directory back structure is the same. As requested by
> the selinux folks. So I don't expect there is much more we can do on
> the /proc side.
>
> When we get the interaction bug between the VFS and /proc/net fixed I wonder
> if there will be some more selinux fall out. Something to think about.
fyi, that machine is x86_32-on-FC5. My x86_64-on-FC6 test box is
also running selinux and has the same bug.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 18:34 ` Andrew Morton
2008-09-04 20:31 ` Eric W. Biederman
@ 2008-09-04 22:45 ` Thomas Gleixner
2008-09-04 23:17 ` Linus Torvalds
2008-09-04 23:17 ` Andrew Morton
1 sibling, 2 replies; 53+ messages in thread
From: Thomas Gleixner @ 2008-09-04 22:45 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Stephen Rothwell, linux-next, LKML, Yinghai Lu,
Ivan Kokshaysky, Jesse Barnes, netdev, Al Viro,
Eric W. Biederman, David Woodhouse, Sam Ravnborg, john stultz
On Thu, 4 Sep 2008, Andrew Morton wrote:
>
> and oh dear, the clockevents code just oopsed.
Sigh.
> BUG: unable to handle kernel NULL pointer dereference at 00000040
> IP: [<c0126e7f>] get_next_timer_interrupt+0xe9/0x1ab
Cute, NULL pointer in the timer check code. Can you please addr2line
the exact code line or upload the vmlinux somewhere ?
Thanks,
tglx
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 22:45 ` Thomas Gleixner
@ 2008-09-04 23:17 ` Linus Torvalds
2008-09-05 5:39 ` Arjan van de Ven
2008-09-04 23:17 ` Andrew Morton
1 sibling, 1 reply; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 23:17 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Andrew Morton, Stephen Rothwell, linux-next, LKML, Yinghai Lu,
Ivan Kokshaysky, Jesse Barnes, netdev, Al Viro,
Eric W. Biederman, David Woodhouse, Sam Ravnborg, john stultz
On Fri, 5 Sep 2008, Thomas Gleixner wrote:
>
> > BUG: unable to handle kernel NULL pointer dereference at 00000040
> > IP: [<c0126e7f>] get_next_timer_interrupt+0xe9/0x1ab
>
> Cute, NULL pointer in the timer check code. Can you please addr2line
> the exact code line or upload the vmlinux somewhere ?
Use "scrips/decodecode" (with AFLAGS=--32 since this is x86-32). It shows
(after some cleanup and editing):
3: 89 f1 mov %esi,%ecx
5: 89 5d d0 mov %ebx,-0x30(%ebp)
8: 8b 45 d0 mov -0x30(%ebp),%eax
b: 89 d3 mov %edx,%ebx
d: 8d 04 c8 lea (%eax,%ecx,8),%eax
10: 89 45 d8 mov %eax,-0x28(%ebp)
13: 8b 00 mov (%eax),%eax
15: eb 14 jmp 0x2b ----------------------+
17: 8b 40 08 mov 0x8(%eax),%eax <--------+ |
1a: bb 01 00 00 00 mov $0x1,%ebx | |
1f: 3b 45 cc cmp -0x34(%ebp),%eax | |
22: 0f 49 45 cc cmovns -0x34(%ebp),%eax | |
26: 89 45 cc mov %eax,-0x34(%ebp) | |
29: 89 d0 mov %edx,%eax | |
*** 2b: 8b 10 mov (%eax),%edx | <-+
2d: 0f 18 02 prefetchnta (%edx) |
30: 90 nop |
31: 3b 45 d8 cmp -0x28(%ebp),%eax |
34: 75 e1 jne 17 ---------------------+
36: 85 db test %ebx,%ebx
38: 89 da mov %ebx,%edx
3a: 74 0c je 0x48
3c: 85 f6 test %esi,%esi
3e: 74 04 je 0x44
and that "prefetchnta" is a dead giveaway: it's a "list_for_each_entry()"
loop. And looking at the registers:
> > Pid: 0, comm: swapper Not tainted (2.6.27-rc5 #18)
> > EIP: 0060:[<c0126e7f>] EFLAGS: 00010013 CPU: 0
> > EIP is at get_next_timer_interrupt+0xe9/0x1ab
> > EAX: 00000040 EBX: 00000001 ECX: 0000001d EDX: 00000040
> > ESI: 0000001d EDI: c05bc700 EBP: c0469f1c ESP: c0469ee4
> > DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> > Process swapper (pid: 0, ti=c0468000 task=c04343c0 task.ti=c0468000)
> > Stack: ffff1cef c013cc1d c05bcf28 00000000 c05bd010 c05bc798 00ffff1d c05bcf28
> > c05bd128 c05bd328 c05bd528 00000000 b65eb8b3 0000000f c0469f4c c013816f
> > 00000000 b65c1f00 0000000f ffff1cef 00000046 00000096 c04b11c0 00000000
> > Call Trace:
> > [<c013cc1d>] ? __lock_acquire+0x671/0x6b7
> > [<c013816f>] ? tick_nohz_stop_sched_tick+0x13f/0x2ba
since %eax == %edx, it's not the first iteration through the loop.
IOW, it's this loop (kernel/timer.c, line 863):
list_for_each_entry(nte, varp->vec + slot, entry) {
found = 1;
if (time_before(nte->expires, expires))
expires = nte->expires;
}
as can be seen by looking at the loop body (that "mov $0x1,%ebx" thing
is the "found = 1;" thing.
The next list entry pointer is obviously corrupt: it's 0x00000040, which
is clearly not a valid pointer.
Looks like %ecx contains 'slot' (0x1d), but that's the only other piece
of info I can see in the register state.
I do wonder if there isn't some memory corruption going on here. The
SElinux thing didn't look very sane either (even if it's a SElinux
permission issue, the inode is corrupt, since the mode is crap).
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 22:45 ` Thomas Gleixner
2008-09-04 23:17 ` Linus Torvalds
@ 2008-09-04 23:17 ` Andrew Morton
2008-09-04 23:25 ` Linus Torvalds
2008-09-04 23:27 ` Thomas Gleixner
1 sibling, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-04 23:17 UTC (permalink / raw)
To: Thomas Gleixner
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, ebiederm, dwmw2, sam, johnstul
On Fri, 5 Sep 2008 00:45:33 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 4 Sep 2008, Andrew Morton wrote:
> >
> > and oh dear, the clockevents code just oopsed.
>
> Sigh.
>
> > BUG: unable to handle kernel NULL pointer dereference at 00000040
> > IP: [<c0126e7f>] get_next_timer_interrupt+0xe9/0x1ab
>
> Cute, NULL pointer in the timer check code. Can you please addr2line
> the exact code line or upload the vmlinux somewhere ?
>
erm, I might have lost that binary, and it only happened the once. It
happened shortly after the machine had fully booted, during
establishment of the first sshd session.
It nuked the machine really well, too. I had to pull the battery to
get it back.
fwiw:
(gdb) l *0xc0126e7f
0xc0126e7f is in get_next_timer_interrupt (kernel/timer.c:863).
warning: Source file is more recent than executable.
858 for (array = 0; array < 4; array++) {
859 struct tvec *varp = varray[array];
860
861 index = slot = timer_jiffies & TVN_MASK;
862 do {
863 list_for_each_entry(nte, varp->vec + slot, entry) {
864 found = 1;
865 if (time_before(nte->expires, expires))
866 expires = nte->expires;
867 }
which looks reasonable.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 23:17 ` Andrew Morton
@ 2008-09-04 23:25 ` Linus Torvalds
2008-09-04 23:27 ` Thomas Gleixner
1 sibling, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2008-09-04 23:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, ebiederm, dwmw2, sam, johnstul
On Thu, 4 Sep 2008, Andrew Morton wrote:
>
> erm, I might have lost that binary, and it only happened the once. It
> happened shortly after the machine had fully booted, during
> establishment of the first sshd session.
Considering that both this and your odd /proc/net issue look like memory
corruption, maybe CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC are worth
testing?
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 23:17 ` Andrew Morton
2008-09-04 23:25 ` Linus Torvalds
@ 2008-09-04 23:27 ` Thomas Gleixner
2008-09-05 11:04 ` Ingo Molnar
1 sibling, 1 reply; 53+ messages in thread
From: Thomas Gleixner @ 2008-09-04 23:27 UTC (permalink / raw)
To: Andrew Morton
Cc: torvalds, sfr, linux-next, linux-kernel, yhlu.kernel, ink,
jbarnes, netdev, viro, ebiederm, dwmw2, sam, johnstul
On Thu, 4 Sep 2008, Andrew Morton wrote:
> >
> > Cute, NULL pointer in the timer check code. Can you please addr2line
> > the exact code line or upload the vmlinux somewhere ?
> >
>
> erm, I might have lost that binary, and it only happened the once. It
> happened shortly after the machine had fully booted, during
> establishment of the first sshd session.
>
> It nuked the machine really well, too. I had to pull the battery to
> get it back.
Known problem on Sonys. :(
> fwiw:
>
> (gdb) l *0xc0126e7f
> 0xc0126e7f is in get_next_timer_interrupt (kernel/timer.c:863).
> warning: Source file is more recent than executable.
> 858 for (array = 0; array < 4; array++) {
> 859 struct tvec *varp = varray[array];
> 860
> 861 index = slot = timer_jiffies & TVN_MASK;
> 862 do {
> 863 list_for_each_entry(nte, varp->vec + slot, entry) {
> 864 found = 1;
> 865 if (time_before(nte->expires, expires))
> 866 expires = nte->expires;
> 867 }
>
> which looks reasonable.
Yeah, as Linus decoded it's that loop. So we look at some corrupted
entry here.
CONFIG_DEBUG_OBJECTS (add debug_objects to the command line as well)
should catch it when this is a timer being discarded, freed or
reinitialized.
Otherwise, when it is just random corruption it wont help much.
Thanks,
tglx
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 23:17 ` Linus Torvalds
@ 2008-09-05 5:39 ` Arjan van de Ven
0 siblings, 0 replies; 53+ messages in thread
From: Arjan van de Ven @ 2008-09-05 5:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Andrew Morton, Stephen Rothwell, linux-next,
LKML, Yinghai Lu, Ivan Kokshaysky, Jesse Barnes, netdev, Al Viro,
Eric W. Biederman, David Woodhouse, Sam Ravnborg, john stultz
On Thu, 4 Sep 2008 16:17:01 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 5 Sep 2008, Thomas Gleixner wrote:
> >
> > > BUG: unable to handle kernel NULL pointer dereference at 00000040
> > > IP: [<c0126e7f>] get_next_timer_interrupt+0xe9/0x1ab
> >
> > Cute, NULL pointer in the timer check code. Can you please addr2line
> > the exact code line or upload the vmlinux somewhere ?
>
> Use "scrips/decodecode" (with AFLAGS=--32 since this is x86-32). It
> shows (after some cleanup and editing):
btw if the oops was on lkml like it was here you can also just look it
up on kerneloops.org via the search option
which for this case finds you
http://www.kerneloops.org/raw.php?rawid=59347&msgid=http://mid.gmane.org/20080904113408.d47c65f6.akpm@linux-foundation.org
and this has the decodecode already done
and the search output at
http://www.kerneloops.org/search.php?search=get_next_timer_interrupt
shows that there's only been very few reports of this one, but of the
ones there were at least half were slab poisoned.
what the site doesn't do for an oops like this is show the C-code
interspersed, it's not that smart for general kernels (that only works
for fedora rpm kernels like here:
http://www.kerneloops.org/raw.php?rawid=57807&msgid=
)
otoh if you have the vmlinux you could do this locally
(hmm maybe I should clean that script up and submit for adding to
the scripts/ directory)
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 23:27 ` Thomas Gleixner
@ 2008-09-05 11:04 ` Ingo Molnar
2008-09-05 17:49 ` Andrew Morton
0 siblings, 1 reply; 53+ messages in thread
From: Ingo Molnar @ 2008-09-05 11:04 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Andrew Morton, torvalds, sfr, linux-next, linux-kernel,
yhlu.kernel, ink, jbarnes, netdev, viro, ebiederm, dwmw2, sam,
johnstul
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 4 Sep 2008, Andrew Morton wrote:
> > >
> > > Cute, NULL pointer in the timer check code. Can you please addr2line
> > > the exact code line or upload the vmlinux somewhere ?
> > >
> >
> > erm, I might have lost that binary, and it only happened the once. It
> > happened shortly after the machine had fully booted, during
> > establishment of the first sshd session.
> >
> > It nuked the machine really well, too. I had to pull the battery to
> > get it back.
>
> Known problem on Sonys. :(
>
> > fwiw:
> >
> > (gdb) l *0xc0126e7f
> > 0xc0126e7f is in get_next_timer_interrupt (kernel/timer.c:863).
> > warning: Source file is more recent than executable.
> > 858 for (array = 0; array < 4; array++) {
> > 859 struct tvec *varp = varray[array];
> > 860
> > 861 index = slot = timer_jiffies & TVN_MASK;
> > 862 do {
> > 863 list_for_each_entry(nte, varp->vec + slot, entry) {
> > 864 found = 1;
> > 865 if (time_before(nte->expires, expires))
> > 866 expires = nte->expires;
> > 867 }
> >
> > which looks reasonable.
>
> Yeah, as Linus decoded it's that loop. So we look at some corrupted
> entry here.
>
> CONFIG_DEBUG_OBJECTS (add debug_objects to the command line as well)
> should catch it when this is a timer being discarded, freed or
> reinitialized.
>
> Otherwise, when it is just random corruption it wont help much.
i guess CONFIG_DEBUG_OBJECTS_TIMERS=y is practical, and
CONFIG_DEBUG_LIST=y would be nice as well - it can catch memory
corruptions rather early and is relatively light-weight.
[ and if there's any reproducability of the corruption and if it happens
at a stable kernel address then a small custom hack in ftrace can
catch it the moment it happens. ]
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-05 11:04 ` Ingo Molnar
@ 2008-09-05 17:49 ` Andrew Morton
0 siblings, 0 replies; 53+ messages in thread
From: Andrew Morton @ 2008-09-05 17:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, torvalds, sfr, linux-next, linux-kernel,
yhlu.kernel, ink, jbarnes, netdev, viro, ebiederm, dwmw2, sam,
johnstul
On Fri, 5 Sep 2008 13:04:11 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > On Thu, 4 Sep 2008, Andrew Morton wrote:
> > > >
> > > > Cute, NULL pointer in the timer check code. Can you please addr2line
> > > > the exact code line or upload the vmlinux somewhere ?
> > > >
> > >
> > > erm, I might have lost that binary, and it only happened the once. It
> > > happened shortly after the machine had fully booted, during
> > > establishment of the first sshd session.
> > >
> > > It nuked the machine really well, too. I had to pull the battery to
> > > get it back.
> >
> > Known problem on Sonys. :(
> >
> > > fwiw:
> > >
> > > (gdb) l *0xc0126e7f
> > > 0xc0126e7f is in get_next_timer_interrupt (kernel/timer.c:863).
> > > warning: Source file is more recent than executable.
> > > 858 for (array = 0; array < 4; array++) {
> > > 859 struct tvec *varp = varray[array];
> > > 860
> > > 861 index = slot = timer_jiffies & TVN_MASK;
> > > 862 do {
> > > 863 list_for_each_entry(nte, varp->vec + slot, entry) {
> > > 864 found = 1;
> > > 865 if (time_before(nte->expires, expires))
> > > 866 expires = nte->expires;
> > > 867 }
> > >
> > > which looks reasonable.
> >
> > Yeah, as Linus decoded it's that loop. So we look at some corrupted
> > entry here.
> >
> > CONFIG_DEBUG_OBJECTS (add debug_objects to the command line as well)
> > should catch it when this is a timer being discarded, freed or
> > reinitialized.
> >
> > Otherwise, when it is just random corruption it wont help much.
>
> i guess CONFIG_DEBUG_OBJECTS_TIMERS=y is practical, and
> CONFIG_DEBUG_LIST=y would be nice as well - it can catch memory
> corruptions rather early and is relatively light-weight.
I tested rc5-mm1 with all debug options except PAGEALLOC. No help.
> [ and if there's any reproducability of the corruption and if it happens
> at a stable kernel address then a small custom hack in ftrace can
> catch it the moment it happens. ]
It was a once-off.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: linux-next: Tree for September 3
2008-09-04 8:50 ` Linus Torvalds
2008-09-04 8:57 ` Andrew Morton
@ 2008-09-09 4:39 ` Jesse Barnes
1 sibling, 0 replies; 53+ messages in thread
From: Jesse Barnes @ 2008-09-09 4:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Stephen Rothwell, linux-next, LKML, Yinghai Lu,
Ivan Kokshaysky
On Thursday, September 04, 2008 1:50 am Linus Torvalds wrote:
> On Thu, 4 Sep 2008, Andrew Morton wrote:
> > <plugs it in>
> >
> > cs: pcmcia_socket0: unable to apply power.
> > pccard: CardBus card inserted into slot 0
> > pci 0000:07:00.0: supports D1
> > pci 0000:07:00.0: supports D2
> > pci 0000:07:00.0: PME# supported from D1 D2 D3hot D3cold
> > pci 0000:07:00.0: PME# disabled
> >
> > sony:/home/akpm> lspci -s07:00
> > 07:00.0 Ethernet controller: 3Com Corporation 3cCFE575CT CardBus
> > [Cyclone] (rev 10)
>
> Ok, the PCI resource side definitely works.
>
> I've committed the fix as follows.. (the explanation is about three times
> the size, but whatever ;)
>
> As to that "unable to apply power" thing, that's a separate issue.. And
> in fact one that probably doesn't even matter to a CardBus card, since
> cardbus doesn't care about the insane CS state machines anyway.
>
> Anyway, Ivan and Jesse cc'd for the patch, but I committed it, since I
> was involved in causing the bug in the first place.
Yeah, looks reasonable. Thanks for pushing it already; I've had crappy to
non-existent network access for the past week...
Thanks,
Jesse
^ permalink raw reply [flat|nested] 53+ messages in thread
* linux-next: Tree for September 3
@ 2010-09-03 3:52 Stephen Rothwell
0 siblings, 0 replies; 53+ messages in thread
From: Stephen Rothwell @ 2010-09-03 3:52 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8127 bytes --]
Hi all,
Changes since 20100902:
The powerpc tree gained a build failure for which I applied a patch.
The galak tree gained a conflict against the powerpc-merge tree.
The net tree lost its build failure.
The input tree lost a conflict.
I still have a patch to the drivers-x86 tree to remove a Kconfig warning.
The tty tree gained a conflict against the microblaze tree.
The usb tree lost its conflicts and build failure.
----------------------------------------------------------------------------
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 171 trees (counting Linus' and 22 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 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 quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
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 gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
CONFLICT (content): Merge conflict in arch/arm/mach-s3c64xx/Makefile
CONFLICT (content): Merge conflict in arch/arm/mach-s3c64xx/mach-smdk6410.c
CONFLICT (content): Merge conflict in arch/arm/plat-samsung/Kconfig
CONFLICT (content): Merge conflict in drivers/input/touchscreen/s3c2410_ts.c
Merging s5p/for-next
Merging tegra/for-next
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
CONFLICT (content): Merge conflict in arch/powerpc/platforms/85xx/mpc85xx_mds.c
Merging s390/features
Merging sh/master
Merging genesis/master
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 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 pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in drivers/media/IR/ir-raw-event.c
CONFLICT (add/add): Merge conflict in drivers/media/video/s5p-fimc/fimc-core.c
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 swiotlb-xen/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
Merging wireless/master
CONFLICT (content): Merge conflict in net/mac80211/main.c
Merging mtd/master
Merging crypto/master
Merging sound-asoc/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-s3c64xx/mach-smdk6410.c
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
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
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging viafb/viafb-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
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 quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
CONFLICT (content): Merge conflict in drivers/net/irda/irda-usb.c
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
Merging i7core_edac/linux_next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging limits/writable_limits
Merging omap_dss2/for-next
Merging xen/upstream/xen
Merging rcu/rcu/next
Merging tip/auto-latest
Merging lost-spurious-irq/lost-spurious-irq
CONFLICT (content): Merge conflict in drivers/ata/libata-core.c
CONFLICT (content): Merge conflict in include/linux/libata.h
Merging edac-amd/for-next
Merging oprofile/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Applying: Fix Kconfig mistaken update
Merging hwpoison/hwpoison
Merging sysctl/master
Merging bkl-core/bkl/core
Merging bkl-procfs/bkl/procfs
Merging bkl-ioctl/bkl/ioctl
Merging quilt/driver-core
Merging quilt/tty
CONFLICT (content): Merge conflict in drivers/serial/uartlite.c
Merging quilt/usb
Merging staging-next/staging-next
Merging slabh/slabh
Merging scsi-post-merge/merge-base:master
$ git checkout scsi-post-merge/master
Applying: powerpc: define a compat_sys_recv cond_syscall
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 53+ messages in thread
* linux-next: Tree for September 3
@ 2009-09-03 11:59 Stephen Rothwell
0 siblings, 0 replies; 53+ messages in thread
From: Stephen Rothwell @ 2009-09-03 11:59 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8825 bytes --]
Hi all,
Changes since 20090902:
The xfs tree lost its build failure.
The acpi tree still has a build failure so I used the version from
next-20090831.
The net tree lost its conflict.
The security-testing tree gained conflicts against the arm and parisc
trees and also a build failure so I used the version of the tree from
next-20090902. There was another build failure due to an interaction with
the net tree for which I applied a merge fix.
The tip tree gained a conflict against the rr tree.
The percpu tree gained a conflict against the tip tree.
The sfi tree gained a conflict against the tip tree.
----------------------------------------------------------------------------
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 141 trees (counting Linus' and 21 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 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/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
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 arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging thumb-2/thumb-2
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
CONFLICT (content): Merge conflict in kernel/gcov/Kconfig
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
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 jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in net/sunrpc/cache.c
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in arch/powerpc/kernel/pci_64.c
Applying: pci: merge fixup for fundamental reset conflict with powerpc tree
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in drivers/media/video/gspca/Kconfig
CONFLICT (content): Merge conflict in drivers/media/video/sh_mobile_ceu_camera.c
Merging quota/for_next
Merging kbuild/master
Merging kconfig/for-next
CONFLICT (content): Merge conflict in scripts/extract-ikconfig
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
$ git reset --hard HEAD^
Merging refs/next/20090831/acpi
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
Merging mmc/next
Merging input/next
CONFLICT (content): Merge conflict in drivers/base/platform.c
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/ubifs/super.c
Merging quilt/device-mapper
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 mfd/for-next
CONFLICT (content): Merge conflict in drivers/input/misc/Kconfig
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in firmware/Makefile
Merging voltage/for-next
CONFLICT (content): Merge conflict in drivers/regulator/Kconfig
Merging security-testing/next
CONFLICT (content): Merge conflict in arch/arm/kernel/signal.c
CONFLICT (content): Merge conflict in arch/parisc/include/asm/thread_info.h
CONFLICT (content): Merge conflict in arch/parisc/kernel/entry.S
CONFLICT (content): Merge conflict in arch/parisc/kernel/signal.c
$ git reset --hard HEAD^
Merging refs/next/20090902/security-testing
Applying: security: fix merge for tun_struct changes
Merging lblnet/master
CONFLICT (content): Merge conflict in drivers/net/tun.c
Merging agp/agp-next
CONFLICT (content): Merge conflict in drivers/char/agp/uninorth-agp.c
Merging uwb/for-upstream
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 omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/socket.h
CONFLICT (content): Merge conflict in arch/x86/kernel/setup.c
CONFLICT (content): Merge conflict in drivers/pci/dmar.c
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in kernel/fork.c
Applying: tip: fix merge for cupmask update
Merging oprofile/for-next
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
Merging edac-amd/for-next
CONFLICT (content): Merge conflict in arch/x86/kernel/smpboot.c
CONFLICT (content): Merge conflict in include/linux/topology.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in kernel/sched.c
Merging sfi/sfi-test
CONFLICT (content): Merge conflict in arch/x86/kernel/setup.c
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/base/class.c
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/tty
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging quilt/usb
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2010-09-03 3:52 UTC | newest]
Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-03 9:16 linux-next: Tree for September 3 Stephen Rothwell
2008-09-04 2:32 ` [PATCH] hid: fix gyration build error Randy Dunlap
2008-09-04 6:52 ` Jiri Slaby
2008-09-04 8:06 ` Jiri Kosina
2008-09-04 4:42 ` linux-next: Tree for September 3 Andrew Morton
2008-09-04 4:46 ` Andrew Morton
2008-09-04 4:54 ` Andrew Morton
2008-09-04 4:57 ` Stephen Rothwell
2008-09-04 5:05 ` Andrew Morton
2008-09-04 5:20 ` Stephen Rothwell
2008-09-04 6:01 ` Andrew Morton
2008-09-04 7:15 ` Andrew Morton
2008-09-04 7:48 ` Stephen Rothwell
2008-09-04 9:19 ` Alan Cox
2008-09-04 9:21 ` Alan Cox
2008-09-04 11:01 ` Alan Cox
2008-09-04 14:35 ` Alan Cox
2008-09-04 5:26 ` Linus Torvalds
2008-09-04 5:42 ` Andrew Morton
2008-09-04 5:00 ` Stephen Rothwell
2008-09-04 5:21 ` Linus Torvalds
2008-09-04 5:33 ` Andrew Morton
2008-09-04 7:14 ` Yinghai Lu
2008-09-04 8:00 ` Andrew Morton
2008-09-04 8:23 ` Linus Torvalds
2008-09-04 8:02 ` Linus Torvalds
2008-09-04 8:25 ` Andrew Morton
2008-09-04 8:37 ` Andrew Morton
2008-09-04 9:03 ` Linus Torvalds
2008-09-04 8:50 ` Linus Torvalds
2008-09-04 8:57 ` Andrew Morton
2008-09-04 9:07 ` Linus Torvalds
2008-09-04 17:45 ` Andrew Morton
2008-09-04 18:05 ` Linus Torvalds
2008-09-04 18:05 ` Linus Torvalds
2008-09-04 18:34 ` Andrew Morton
2008-09-04 20:31 ` Eric W. Biederman
2008-09-04 20:41 ` Andrew Morton
2008-09-04 20:41 ` Andrew Morton
2008-09-04 21:03 ` Eric W. Biederman
2008-09-04 22:22 ` Andrew Morton
2008-09-04 22:22 ` Andrew Morton
2008-09-04 22:45 ` Thomas Gleixner
2008-09-04 23:17 ` Linus Torvalds
2008-09-05 5:39 ` Arjan van de Ven
2008-09-04 23:17 ` Andrew Morton
2008-09-04 23:25 ` Linus Torvalds
2008-09-04 23:27 ` Thomas Gleixner
2008-09-05 11:04 ` Ingo Molnar
2008-09-05 17:49 ` Andrew Morton
2008-09-09 4:39 ` Jesse Barnes
2009-09-03 11:59 Stephen Rothwell
2010-09-03 3:52 Stephen Rothwell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.