login
Search
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 ...
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 --
Acked-by: Jiri Slaby <jirislaby@gmail.com> Thanks for catching this. My cut&paste typo. --
Applied, thanks for catching it. -- Jiri Kosina SUSE Labs --
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 ...
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
...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.
--
Hi Andrew, On Wed, 3 Sep 2008 21:54:55 -0700 Andrew Morton <akpm@linux-foundation.org>= No it isn't because it came from dwmw2's tree and that has already been rewritten/rebased ... --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Thank gawd for that. This breakage spans over 1000 commits. Not sure how that can happen in a rebased tree, but whatever. --
Hi Andrew, On Wed, 3 Sep 2008 22:05:46 -0700 Andrew Morton <akpm@linux-foundation.org>= 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. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
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>] ? ...
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 ...Hi Andrew, On Thu, 4 Sep 2008 00:15:58 -0700 Andrew Morton <akpm@linux-foundation.org>= 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). --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
On Thu, 4 Sep 2008 00:15:58 -0700 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" --
What does an strace of the getty tasks show ? --
> 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 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 --
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();
--
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 --
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. --
Hi Andrew, On Wed, 3 Sep 2008 21:54:55 -0700 Andrew Morton <akpm@linux-foundation.org>= r '__attribute__' before '__u32' for a short term fix, apply the "statfs: fix typo" commit from right near the end of next-20080903. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
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: "
...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 ...
On Wed, Sep 3, 2008 at 10:33 PM, Andrew Morton 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
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 ...
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
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 ...so it fixed _one_ issue.
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.
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
--
<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". --
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 ...Heh. I'm hoping that it would help to just change vcc_settle to 50
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
...
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
--
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 ...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 --
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
--
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. 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 --
I don't think I saw it on any other test machines.
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 ...There aren't any issues I know of with normal configurations Does the problem happen if you disable selinux? This feels like a case of selinux being over zealous. Eric --
On Thu, 04 Sep 2008 13:31:01 -0700 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 --
On Thu, 04 Sep 2008 14:03:41 -0700 fyi, that machine is x86_32-on-FC5. My x86_64-on-FC6 test box is also running selinux and has the same bug. --
Cute, NULL pointer in the timer check code. Can you please addr2line the exact code line or upload the vmlinux somewhere ? Thanks, tglx --
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()"
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 ...On Thu, 4 Sep 2008 16:17:01 -0700 (PDT) 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/200809041... 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 --
On Fri, 5 Sep 2008 00:45:33 +0200 (CEST)
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.
--
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 --
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 --
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 --
It was a once-off. --
Yeah, looks reasonable. Thanks for pushing it already; I've had crappy to non-existent network access for the past week... Thanks, Jesse --
