lkml.org 
[lkml]   [2006]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
"Carlo E. Prelz" <fluido@fluido.as> wrote:
>
> Subject: Re: ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15 rc1
> Date: sab 21 gen 06 01:09:32 -0800
>
> Quoting Andrew Morton (akpm@osdl.org):
>
> > Can you please add `initcall_debug' to the kernel boot command line?
> > That'll tell us which function got stuck.
>
> I photographed the screen. I am copying here the last few lines. I
> hope I make no errors in copying...

Thanks. That's probably more lines than we needed ;)

If you have a web server somewhere, just upload the .jpg file. Or send it
to me and I can do that.

> ...
> ...
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> Calling initcall 0xffffffff806de042: init_nlm+0x0/0x21()
> Calling initcall 0xffffffff806de063: init_nls_cp437+0x0/0xc()
> Calling initcall 0xffffffff806de06f: init_nls_cp850+0x0/0xc()
> Calling initcall 0xffffffff806de07b: init_nls_cp852+0x0/0xc()
> Calling initcall 0xffffffff806de087: init_nls_iso8859_1+0x0/0xc()
> Calling initcall 0xffffffff806de093: init_nls_iso8859_15+0x0/0xc()
> Calling initcall 0xffffffff806de09f: init_nls_utf8+0x0/0x1f()
> Calling initcall 0xffffffff806de0be: init_autofs4_fs+0x0/0xc()
> Calling initcall 0xffffffff806de0ca: init_udf_fs+0x0/0x53()
> Calling initcall 0xffffffff806de11d: ipc_init+0x0/0x14()
> Calling initcall 0xffffffff806de2ea: init_mqueue_fs+0x0/0xc7()
> Calling initcall 0xffffffff806de51d: key_proc_init+0x0/0x52()
> Calling initcall 0xffffffff806de67c: init_crypto+0x0/0x18()
> Initializing Cryptographic API
> Calling initcall 0xffffffff806de6b4: init+0x0/0xc()
> Calling initcall 0xffffffff806de6c0: init+0x0/0xc()
> Calling initcall 0xffffffff806de6cc: init+0x0/0xc()
> Calling initcall 0xffffffff806de6d8: init+0x0/0xc()
> Calling initcall 0xffffffff806de6e4: init+0x0/0x35()
> Calling initcall 0xffffffff806de719: init+0x0/0x5a()
> Calling initcall 0xffffffff806de773: init+0x0/0x5a()
> Calling initcall 0xffffffff806de7cd: init+0x0/0x35()
> Calling initcall 0xffffffff806de802: init+0x0/0xc()
> Calling initcall 0xffffffff806de80e: init+0x0/0xc()
> Calling initcall 0xffffffff806de81a: init+0x0/0x35()
> Calling initcall 0xffffffff806de84f: init+0x0/0xc()
> Calling initcall 0xffffffff806de85b: init+0x0/0xc()
> Calling initcall 0xffffffff806de867: arc4_init+0x0/0xc()
> Calling initcall 0xffffffff806de873: init+0x0/0x5a()
> Calling initcall 0xffffffff806de8cd: init+0x0/0xc()
> Calling initcall 0xffffffff806de8d9: init+0x0/0xc()
> Calling initcall 0xffffffff806de8e5: init+0x0/0xc()

Oh dear. We have 394 funtions all called 'init()' in the kernel.
netfilter is a prime source.

> Calling initcall 0xffffffff806de8f1: michael_mic_init+0x0/0xc()
> Calling initcall 0xffffffff806de8fd: init+0x0/0xc()
> Calling initcall 0xffffffff806dea0a: noop_init+0x0/0xc()
> Scheduler noop registered
> Calling initcall 0xffffffff806dea16: as_init+0x0/0x4f()
> Scheduler anticipatory registered
> Calling initcall 0xffffffff806dea65: deadline_init+0x0/0x4f()
> Scheduler deadline registered
> Calling initcall 0xffffffff806deab4: cfq_init+0x0/0xc4()
> Scheduler cfq registered
> Calling initcall 0xffffffff8026836c: pci_init+0x0/0x2b()
>
>
> And then the machine freezes. I may add that, with 2.6.14.6, I am
> getting errors like:

OK, it looks like a PCI initcall went South. Can you please add this, then
when it hangs, record the last few lines then send us those, as well as the
output of `lspci -vx'?

--- devel/drivers/pci/pci.c~a 2006-01-21 12:55:38.000000000 -0800
+++ devel-akpm/drivers/pci/pci.c 2006-01-21 12:56:51.000000000 -0800
@@ -886,6 +886,7 @@ static int __devinit pci_init(void)
struct pci_dev *dev = NULL;

while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ printk("pci_init: %04x%04x\n", dev->vendor, dev->device);
pci_fixup_device(pci_fixup_final, dev);
}
return 0;
_

> APIC error on CPU0: 04(40)
>
> or, more often
>
> APIC error on CPU0: 40(40)
>
> I tried either to pass noapic, or to disable apic in bios, and the
> kernel entered a slow process of testing and refusing all addresses of
> my SCSI card (I tried both an Advansys and a NCR: the result has been
> the same) and then eventually gave an oops in ifconfig. I haven't
> photographed those messages, but I will do so if needed.
>

Is this new behaviour? If so, are you able to pinpoint the latest kernel
which didn't have such problems?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-21 22:01    [W:0.069 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site