lkml.org 
[lkml]   [1999]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Weird Oops on 2.2.13 (how to debug this one?)

On Mon, 22 Nov 1999, Richard B. Johnson wrote:
>
> > I'm debugging a new synchronous card driver, and even though the driver
> > seems stable, sometimes I get kernel oopsen like the one below when doing
> > an FTP reception transfer:
> >
> > Unable to handle kernel paging request at virtual address c4834824
> > current->tss.cr3 = 00101000, %cr3 = 00101000
> > *pde = 00000000
> > Oops: 0000
> > CPU: 0
> > EIP: 0010:[<c4834824>]
> > EFLAGS: 00010292
> > eax: 00000009 ebx: 00000002 ecx: 00000001 edx: c281908c
> > esi: c2819070 edi: 00000001 ebp: c289e048 esp: c01dff1c
> > ds: 0018 es: 0018 ss: 0018
> > Process swapper (pid: 0, process nr: 0, stackpage=c01df000)
> > Stack: f1e85200 83fffb77 c8e904c4 90000000 28244c8b 8308798b 387501ff
> > 448b016a
> > e8504424 fffb8264 4824748b f008c483 187eab0f c085c019 016a1a75
> > 76bee856
> > c483fffb 287e8308 56097402 fb76efe8 04c483ff 4024548b 0974d285
> > 7796e852
> > Call Trace:
> > Code:
> >
> > The weird thing about it is that there is no call trace nor code to be
> > used in the ksymoops. If I try to use all I got in ksymoops (i.e., the
> > output shown above), it doesn't return anything, i.e., it stays there
> > waiting for actually useful data to come in.
>
> You probably don't have any global symbols that ksymoops can use in your
> driver. You can always load your driver with debugging info, i.e.,
>
> #ifdef DEBUG
> #define DEB(f) f
> #else
> #define DEB(f)
> #endif
>
> DEB(printk("address was %p\n", foo));
>
> In this case, if DEBUG is not defined, DEB(x) goes away entirely.

Almost every function in my driver is exported (only during this
debugging phase, of course). Nevertheless, even if it wasn't, the kernel
oops output should still show the call trace (even though ksymoops
wouldn't be able to translate it to symbols), do you agree??

> Since the paging address looks reasonable, it looks as though there
> is some reason why a page-fault could not be done. This is usually
> caused by somebody trying to write to user-space while holding a lock.

This driver does not write to / read from userspace, except in case of
certain IOCTLs, which are not called when the problem happens. Anyhow,
these copies_[to|from]_user are not spinlocked.

> This cannot be done. Also space dynamically allocated in an interrupt
> has to be GFP_ATOMIC. If you need to copy this data to user-space
> under a lock, it has to be done in two steps:
>
> spinlock_t device_lock;
> long flags;
> spin_lock_irqsave(&device_lock, flags); /* No interrupts */
> memcpy(tmp_buffer, interrupt_buffer, length); /* Get interrupt data */
> spin_unlock_irqrestore(&device_lock, flags); /* Allow interrupts */
> copy_to_user(user_buf, tmp_buffer, length); /* Copy to user */

Any other hints??

If anybody needs to have a look at the code, please let me know (I don't
want to send it to the whole list, just to save BW).

Regards,
Ivan


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

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.097 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site