Re: [kernel panic @ reboot in usbcore] 2.6.0-test10-mm1 (culprit: modem_run)

• Previous message: David S. Miller: "Re: 2.4.23-rc4 sparc64 compile problem: drivers/char/drm/ffb_drv.c"
• In reply to: Vince: "Re: [kernel panic @ reboot in usbcore] 2.6.0-test10-mm1 (culprit: modem_run)"
• Next in thread: Randy.Dunlap: "Re: [kernel panic @ reboot] 2.6.0-test10-mm1"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: Vince <fuzzy77@free.fr>, Zwane Mwaikambo <zwane@arm.linux.org.uk>
Date:	Thu, 27 Nov 2003 09:11:17 +0100

This looks like a problem I have been seeing. I have a fix for this
in the works. Unfortunately I'm pretty busy right now, so I can't
say when I'll have it ready. The problem is in drivers/usb/core/devio.c.
Actually there are lots of problems in devio.c :) One problem is that
devio.c is not protected against actconfig changing under it (thanks
to a usb core change, it becomes NULL before becoming something
else, which causes devio.c to oops rather than quietly do the wrong
thing). The use of dev->serialize (usb semaphore) in releaseintf is
also wrong because it can lead to deadlock. Another problem comes
from devio.c (i.e. usbfs) thinking that disconnects are for the whole
device and not just an interface. Furthermore, there are various
oopsen that come from devio.c not handling urb unlink failures.
That's all I remember off the top of my head :) I sent a couple of
emails about this (especially the locking problems) to the usb
mailing list lately. Hang on, I just remembered another one:
releaseintf needs to be called with a write lock taken on
ps->devsem rather than a read lock, otherwise it can boot other
parts of devio.c off an interface when they think they still have
it.

Ciao,

Duncan.

On Thursday 27 November 2003 01:59, Vince wrote:
> It worked, but I had -- as expected -- to write the oops by hand.
> (user request to Randy: would it be possible to have an option in
> kmsgdump to only write the first oops on floppy ???)
>
> I it have all on paper, but I'm too lazy to write the full stack right
> now (available later on request: I have to go to bed now 8):
>
> ------------------------------------------------------------------
> CPU: 0
> EIP: 0060 : [<d0ae9822>]
> EFLAGS: 00010246
> EIP is at releaseintf+0x62/0x80 [usbcore]
> eax:00000000 ebx:ceddc224 ecx:cs6D5DC0 edx:00000000
> esi:ceddc200 edi:00000000 ebp:cd647f0c esp:cd647ef8
> ds: 007b es:007b ss:0068
>
> Process: modem_run (pid: 1121, threadinfo=cd646000, task=ce644040)
> Stack: c016ffe3 ce0bfb24 ce6d5dc0 ...
> [...]
>
> Call trace
> [<c016ffe3>] iput+0x63/0x80
> [<d0ae9c27>] usbdev_release+0xb7/0xc0 [usbcore]
> [<c0157a5c>] __fput+0x10c/0x120
> [<c0156047>] filp_close+0x57/0x80
> [<c0123d17>] put_files_struct+0x67/0xd0
> [<c012491e>] do_exit+0x3a/0xb0
> [<c0124c4a>] do_group_exit+0x3a/0xb0
> [<c02a302e>] sysenter_past_esp+0x43/0x65
> -------------------------------------------------------------------
>
> The modem_run process is the one uploading the firmware for my
> speedtouch dsl modem. I'm using the kernel-space speedtouch driver, with
> modem_run from http://speedtouch.sourceforge.net/
> Manually shutting down the network and killing modem_run before
> rebooting makes the oops disapear.
>
> However, I believe the fact that modem_run can cause a kernel panic is
> still a bug that should be fixed. I'm willing to test any patch to fix
> this issue that has ennoyed me since a long time (in the meantime, I'll
> work around this in my shutdown scripts). :-)
>
> Zwane Mwaikambo wrote:
> > On Wed, 26 Nov 2003, Vince wrote:
> >>>*groan* do you have a PDA?
> >>
> >>Nope. I could probably borrow a laptop to a friend but am not excited at
> >>the idea of having to setup some serial console thing (I do not even
> >>have a serial cable). Dump to floppy/swap/disk would be much easier in
> >>my case... if it could me made to work, of course ;-)
> >
> > Those oopses looked rather spurious, i'm not sure what help those other
> > methods would be here. Try applying the following patch and be sure to
> > have access to the console. You may have to hand transcribe...
> >
> > Index: linux-2.6.0-test10-mm1-bochs/arch/i386/kernel/traps.c
> > ===================================================================
> > RCS file:
> > /build/cvsroot/linux-2.6.0-test10-mm1/arch/i386/kernel/traps.c,v
> > retrieving revision 1.1.1.1
> > diff -u -p -B -r1.1.1.1 traps.c
> > --- linux-2.6.0-test10-mm1-bochs/arch/i386/kernel/traps.c 26 Nov 2003
> > 05:28:50 -0000 1.1.1.1 +++
> > linux-2.6.0-test10-mm1-bochs/arch/i386/kernel/traps.c 26 Nov 2003
> > 18:17:37 -0000 @@ -329,6 +329,10 @@ void die(const char * str, struct
> > pt_reg
> > if (in_interrupt())
> > panic("Fatal exception in interrupt");
> >
> > + local_irq_disable();
> > + while (1)
> > + __asm__ __volatile__("hlt");
> > +
> > if (panic_on_oops) {
> > printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
> > set_current_state(TASK_UNINTERRUPTIBLE);
>
> -
> 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/
-
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/

• Previous message: David S. Miller: "Re: 2.4.23-rc4 sparc64 compile problem: drivers/char/drm/ffb_drv.c"
• In reply to: Vince: "Re: [kernel panic @ reboot in usbcore] 2.6.0-test10-mm1 (culprit: modem_run)"
• Next in thread: Randy.Dunlap: "Re: [kernel panic @ reboot] 2.6.0-test10-mm1"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]