Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: OOPS with budget card + cam (in dvb_ca_en50221_io_write)
I started this thread a couple of months ago. Here is some quoted text
from the past mails to help you remember what this is about.
Subject: Re: [linux-dvb] Re: OOPS with budget card + cam (in dvb_ca_en50221_io_write)
Date: Thu, Sep 16, 2004 at 08:06:34AM +0200
Quoting Carlo E. Prelz (fluido@fluido.as):
> Subject: Re: [linux-dvb] Re: OOPS with budget card + cam (in dvb_ca_en50221_io_write)
> Date: mer, set 15, 2004 at 11:39:46 +0100
>
> Quoting Andrew de Quincey (adq_dvb@lidskialf.net):
>
> > Hi, this is coming from the middle of the msleep() call in
> > dvb_ca_en50221_io_write() - nothing to do with me (heheheh! :)
>
> Lucky man...!
>
> > You're using kernel 2.6.8.1. I had to downgrade to 2.6.7 because of massive
> > problems with that kernel (specifically NFS, but this looks like the same
> > kind of error). Do you have the preemptible kernel stuff turned on? That was
> > what caused it for me.
> >
> > I upgraded to 2.6.9-rc2 last night - it seems fine so far.
>
> Thanks very much for this. Yes, CONFIG_PREEMPT was on. Now switching
> to 2.6.9-rc2.
During these two months, I spent extended periods abroad, and could
not give too much attention to that system. The current situation is
as follows:
* downgraded to 2.6.7 because the parallel port support on 2.6.9-rc2
was broken for my parport.
* CONFIG_PREEMPT *disabled*
* dvb-kernel cvs from 5 September
The very irregular oops goes on hitting the system. Here is what
happened this morning:
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Unable to handle kernel NULL pointer dereference at virtual address 00000010
printing eip:
e1a0f46c
*pde = 00000000
Oops: 0000 [#3]
Modules linked in: stv0299 budget_ci budget_core dvb_core saa7146 ttpci_eeprom b44 8139too
CPU: 0
EIP: 0060:[<e1a0f46c>] Not tainted
EFLAGS: 00010202 (2.6.7)
EIP is at dvb_ca_en50221_io_write+0xac/0x1e0 [dvb_core]
eax: 00000000 ebx: 00000000 ecx: 00000000 edx: fffffff2
esi: 00000000 edi: d8e4c1c4 ebp: 00000003 esp: cd2add44
ds: 007b es: 007b ss: 0068
Process harvest_periods (pid: 8497, threadinfo=cd2ac000 task=d0bcb210)
Stack: cd2add5e 41d5e101 00000001 00000005 00000003 00000000 0001fde4 00000001
01a00001 c0115101 cc85c7f0 00000003 00000000 00000000 00000001 c1400ab0
c0114308 c403fde4 00000003 00000082 00000000 c11b5ae0 dffae6e8 00000001
Call Trace:
[<c0115101>] prepare_to_wait_exclusive+0x11/0x50
[<c0114308>] __wake_up_common+0x38/0x60
[<c012fa59>] mempool_free+0x39/0x80
[<c012fa59>] mempool_free+0x39/0x80
[<c012fa59>] mempool_free+0x39/0x80
[<c029c297>] freed_request+0xa7/0xb0
[<c0114023>] scheduler_tick+0x163/0x3f0
[<c011de86>] update_process_times+0x46/0x60
[<c011dceb>] update_wall_time+0xb/0x40
[<c011e11f>] do_timer+0xdf/0xf0
[<c011a4bd>] __do_softirq+0x7d/0x80
[<c0105ac5>] do_IRQ+0xc5/0xe0
[<c012cf63>] wake_up_page+0x13/0x40
[<c012d08f>] unlock_page+0x1f/0x30
[<c013a3b1>] do_wp_page+0x1d1/0x230
[<c0104068>] common_interrupt+0x18/0x20
[<c013aed9>] handle_mm_fault+0x159/0x170
[<c03efa72>] schedule+0x272/0x430
[<c03effad>] schedule_timeout+0x6d/0xc0
[<e1a0f3c0>] dvb_ca_en50221_io_write+0x0/0x1e0 [dvb_core]
[<c0147a7c>] vfs_write+0xdc/0x140
[<c011e30e>] sys_nanosleep+0xde/0x170
[<c0147b92>] sys_write+0x42/0x70
[<c0103efb>] syscall_call+0x7/0xb
Code: 8b 53 10 0f b6 c1 c1 e0 06 83 3c 02 02 0f 85 f4 00 00 00 39
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Has some change in these two months taken place which could solve the
above? It is quite complex for me to experiment with this system, so I
would be sure there are reasons for try more modern code.
Thanks...
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
Home |
Main Index |
Thread Index