[linux-dvb] Re: OOPS with budget card + cam (in dvb_ca_en50221_io_write)

["Carlo E. Prelz" <fluido@fluido.as>]

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)