by Benjamin Herrenschmidt

[permalink] [raw]

Subject: Re: 2.6.11-rc3-mm1

On Fri, 2005-02-04 at 22:17 +0000, Sean Neakums wrote:
> I gave this a crack on the PowerBook5.4 -- somewhat more successful
> than 2.6.11-rc2-mm2. It boots, radeonfb works and X starts. However,
> suspend seems a tad faster than usual, and resume stops after setting
> the hard disk's DMA mode, although the log below made it to disk.

Looks like USB is dying on wakeup... Anyway, that's still better than
2.6.11 since your model will not sleep/wakeup at all without these
patches.

I'll have to look into the USB thing. From the error messages, it looks
like at least some of my patches removing some old pmac IRQ cruft from
the ohci driver didn't make it (I though david picked it up a while ago
though). Or it could be a problem with the interrupt controller, I've
had reports of cases where the PIC just stops working on resume, I'm
still investigating.

Is this totally reproduceable or does it wake up sometimes ? Have you
tried with USB disabled ?

Ben.

2005-02-05 01:00:24

On Feb 05 2005, Rog?rio Brito wrote:
> I am including the dmesg log of my system with this message.
(...)

Ooops! Forgot to include the dmesg in the previous message. :-(

Thanks again, Rog?rio.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rog?rio Brito - [email protected] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Attachments:

(No filename) (409.00 B)
dmesg.txt (14.99 kB)
Download all attachments

2005-02-06 02:36:27

by William Park

[permalink] [raw]

Subject: Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> Dear developers,
>
> For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> some -mm trees and also -ac) I have been getting the message "irq 10:
> nobody cared!".
>
> The message says that I should pass the irqpoll option to the kernel and
> even if I do, I still get the stack trace and the "irq 10: nobody cared!"
> message. :-(
>
> The message seems to be related to the Promise PDC20265 driver and it
> appeared right after I moved my HDs from my motherboard's VIA controllers
> to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
> controllers and 2 Promise PDC20265 controllers.
>
> I already tried enabling and disabling ACPI, but it seems that the problem
> just doesn't go away. :-(
>
> I am including the dmesg log of my system with this message. I am CC'ing
> the linux-ide list, but I'm only subscribed to linux-kernel. I would
> appreciate CC's, if possible.
>
>
> Thank you very much for any help, Rog?rio.
>
> P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
> kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'. It did it for me (Abit VP6 dual-p3, Via VT82C694X,
Via VT82C686B).

--
William Park <[email protected]>, Toronto, Canada
Slackware Linux -- because I can type.

2005-02-06 09:11:14

Robert Love <[email protected]> writes:

> On Sun, 2005-02-06 at 22:22 +0100, Peter Osterlund wrote:
>
> > > > > EIP is a strncpy_from_user+0x33/0x47
> > > > > ...
> > > > > Call Trace:
> > > > > getname+0x69/0xa5
> > > > > sys_open+0x12/0xc6
> > > > > sysenter_past_esp+0x52/0x75
> > > > > ...
> > > > > Kernel panic - not syncing: Attempted to kill init!
> >
> > I found the if I disable CONFIG_INOTIFY, the problem goes away.
>
> Weird. While we touch sys_open() with an inotify hook, we do so after
> the call to getname, and we don't touch getname() or strncpy_from_user()
> at all.
>
> I wonder if there is another bug and inotify is just affecting the
> timing?

Possible, but it fails every time with CONFIG_INOTIFY enabled and
works every time with CONFIG_INOTIFY disabled.

I added some printk's to do_getname and got this:

...
Freeing unused kernel memory: 160k freed
...
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:455dd11f len:4096
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:455dd11f len:4096
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:455dd11f len:4096
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:00000000 len:4096
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c01d8257
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in:
CPU: 0
EIP: 0060:[<c01d8257>] Not tainted VLI
EFLAGS: 00010206 (2.6.11-rc3-mm1)
EIP is at strncpy_from_user+0x33/0x47
eax: c14f0000 ebx: fffffff2 ecx: 00001000 edx: 00001000
esi: 00000000 edi: df404000 ebp: 00000000 esp: c14f1f60
ds: 007b es: 007b ss: 0068
Process init (pid: 1, threadinfo=c14f0000 task=dff4ba40)
Stack: c14f0000 fffffff4 df404000 00000000 c0166854 df404000 00000000 00001000
df404000 00000000 00001000 00001000 00000000 00000000 00000901 c14f0000
c0158725 00000000 00000000 00000000 00000002 00000000 00000000 00000901
Call Trace:
[<c0166854>] getname+0xb4/0x10f
[<c0158725>] sys_open+0x12/0xc6
[<c0102f19>] sysenter_past_esp+0x52/0x75
Code: 57 56 53 bb f2 ff ff ff 8b 74 24 18 8b 7c 24 14 8b 4c 24 1c 89 f2 83 c2 01 19 ed 39 50 18 83 dd 00 85 ed 75 13 89 ca 85 c9 74 0b <ac> aa 84 c0 74 03 49 75 f7 29 ca 89 d3 89 d8 5b 5e 5f 5d c3 57
do_getname: hotplug seg:1 page:dfca1000 filename:080e6770 len:4096
do_getname: hotplug /etc/hotplug.d/default/20-hal.hotplug
do_getname: hotplug seg:1 page:df6d1000 filename:080e6770 len:4096
do_getname: hotplug /etc/hotplug.d/default/20-hal.hotplug
Kernel panic - not syncing: Attempted to kill init!

If I add this code to do_getname()

+ if (!filename)
+ return -EFAULT;

the machine boots correctly, but then fails later when trying to start
the X server:

Unable to handle kernel paging request at virtual address 00008050
printing eip:
c01d840a
*pde = 16fd4067
*pte = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in: radeon joydev mousedev nfs psmouse snd_atiixp_modem nfsd exportfs lockd parport_pc lp parport autofs4 pcmcia sunrpc ipt_LOG ipt_limit ipt_state ipt_REJECT iptable_filter ipt_MASQUERADE iptable_nat ip_tables binfmt_misc dm_mod yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd ehci_hcd usbcore ide_cd cdrom
CPU: 0
EIP: 0060:[<c01d840a>] Not tainted VLI
EFLAGS: 00013246 (2.6.11-rc3-mm1)
EIP is at __copy_to_user_ll+0x3c/0x64
eax: 00000000 ebx: 00008050 ecx: 00000002 edx: 00008058
esi: e1a5cc67 edi: 00008050 ebp: ffffffff esp: d75e9e58
ds: 007b es: 007b ss: 0068
Process X (pid: 4757, threadinfo=d75e8000 task=d7584020)
Stack: 00000027 00008050 00000000 00000000 e1a5cc70 c01d84ce 00008050 e1a5cc67
00000008 00000008 d75e9ec8 e1a51140 00008050 e1a5cc67 00000008 00000000
d75e9f08 c01d8511 d75e9f08 bfd4a320 d7957800 bfd4a320 d75e9f08 ffffffea
Call Trace:
[<c01d84ce>] copy_to_user+0x38/0x42
[<e1a51140>] version+0xe8/0x138 [radeon]
[<c01d8511>] copy_from_user+0x39/0x68
[<c02524e0>] drm_setversion+0x49/0x11b
[<c0251219>] drm_ioctl+0xeb/0x1c1
[<c0106407>] handle_vm86_fault+0x78f/0x909
[<c0106407>] handle_vm86_fault+0x78f/0x909
[<c016bac7>] do_ioctl+0x57/0x85
[<c0106407>] handle_vm86_fault+0x78f/0x909
[<c016bcc8>] vfs_ioctl+0x5c/0x1c3
[<c0106407>] handle_vm86_fault+0x78f/0x909
[<c016be6b>] sys_ioctl+0x3c/0x59
[<c0106407>] handle_vm86_fault+0x78f/0x909
[<c0102f19>] sysenter_past_esp+0x52/0x75
[<c0106407>] handle_vm86_fault+0x78f/0x909
Code: 83 f9 3f 76 0c 89 f8 31 f0 85 05 80 bd 44 c0 75 28 89 c8 83 f9 07 76 17 89 f9 f7 d9 83 e1 07 29 c8 f3 a4 89 c1 c1 e9 02 83 e0 03 <f3> a5 89 c1 f3 a4 83 c4 0c 5e 89 c8 5f c3 89 4c 24 08 89 74 24
<3>[drm:drm_release] *ERROR* Device busy: 1 0

Patch used during tests:

diff -puN fs/namei.c~panic-debug fs/namei.c
--- linux/fs/namei.c~panic-debug 2005-02-08 23:06:54.604431440 +0100
+++ linux-petero/fs/namei.c 2005-02-08 23:52:26.585107248 +0100
@@ -116,15 +116,28 @@ static inline int do_getname(const char
{
int retval;
unsigned long len = PATH_MAX;
+ int segment = 0;

if (!segment_eq(get_fs(), KERNEL_DS)) {
+ segment = 1;
if ((unsigned long) filename >= TASK_SIZE)
return -EFAULT;
if (TASK_SIZE - (unsigned long) filename < PATH_MAX)
len = TASK_SIZE - (unsigned long) filename;
}

+#if 0
+ printk("do_getname: %s seg:%d page:%p filename:%p len:%ld\n",
+ current->comm, segment, page, filename, len);
+#endif
+
+ if (!filename)
+ return -EFAULT;
+
retval = strncpy_from_user(page, filename, len);
+#if 0
+ printk("do_getname: %s %s\n", current->comm, page);
+#endif
if (retval > 0) {
if (retval < len)
return 0;

--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340

2005-02-09 03:59:13

[permalink] [raw]

Subject: Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

On Feb 12 2005, William Park wrote:
> Do you have MSI on by any chance? (CONFIG_PCI_MSI) If so, try kernel
> without it. My motherboard exhibits runaway IRQ with it.

Ok, now I've just downloaded the -rc4 patch and while selecting the options
to compile, I saw what MSI means. No, I didn't have MSI enabled.

I guess tha I could try a compile with it enabled? I enabled the ACPI
debugging messages, just in case it helps.

I will now compile the new kernel. Let's see if the debugging messages help
here.

Hope this information is useful, Rog?rio.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rog?rio Brito - [email protected] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2005-02-13 18:49:30

by Rogério Brito

[permalink] [raw]

Subject: [Partially solved] Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

Hi, William.

On Feb 12 2005, William Park wrote:
> Your 'dmesg' says
> Warning: Secondary channel requires an 80-pin cable for operation.
> I assume it is.

Well, I just finished compiling the 2.6.11-rc4 kernel and the problem
persisted. This time, I enabled ACPI debugging and it indeed generates more
details.

Right after the problem persisted, I turned off the second HD (which was
the master of the secondary channel of the Promise controller) and the
problem automagically went away. :-(

One other thing is that the BIOS still configures the drive as UDMA 4, but
Linux downgrades that to UDMA 2. I'm not sure why.

Using hdparm manually with "hdparm -c1 -u1 -d1 -X udma4 /dev/hde" enables
things that the kernel doesn't and seems to be working wonderfully.

I don't know what I should do right now. I have put the newer dmesg logs on
<http://www.ime.usp.br/~rbrito/ide-problem/>. Should I contact anybody else?
I do need the second drive on, though.

I'm CC'ing Bartlomiej Zolnierkiewicz, as he is listed in the MAINTAINERS
file as the IDE maintainer.

Thanks for any comments and help, Rog?rio Brito.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rog?rio Brito - [email protected] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=