Whilst we've fixed the recurring IRQ issue some times we still get the NMI Issue that I first talked about. Sometimes when I boot up I get this problem other times I do not. I've run memtest86+ for one pass and it came up with nothing... I'll try a longer run during my lunch break just to make sure but I don't believe it is a RAM issue. Heres the output to /var/log/messages Jul 13 16:27:34 bloodhound kernel: Uhhuh. NMI received. Dazed and confused, but trying to continue Jul 13 16:27:34 bloodhound kernel: You probably have a hardware problem with your RAM chips Jul 13 16:27:34 bloodhound kernel: irq 11: nobody cared! Jul 13 16:27:34 bloodhound kernel: [<c014efc4>] __report_bad_irq+0x24/0x7d Jul 13 16:27:34 bloodhound kernel: [<c014f0a6>] note_interrupt+0x6b/0x89 Jul 13 16:27:34 bloodhound kernel: [<c014e5c1>] __do_IRQ+0x180/0x2ff Jul 13 16:27:34 bloodhound kernel: [<c011b6d2>] scheduler_tick+0x1a/0x4d4 Jul 13 16:27:34 bloodhound kernel: [<c0105928>] do_IRQ+0x69/0x85 Jul 13 16:27:34 bloodhound kernel: [<c0103aea>] common_interrupt+0x1a/0x20 Jul 13 16:27:34 bloodhound kernel: [<c014e407>] handle_IRQ_event+0x28/0x62 Jul 13 16:27:34 bloodhound kernel: [<c014e4ff>] __do_IRQ+0xbe/0x2ff Jul 13 16:27:34 bloodhound kernel: [<c010590b>] do_IRQ+0x4c/0x85 Jul 13 16:27:34 bloodhound kernel: ======================= Jul 13 16:27:34 bloodhound kernel: [<c012c6e0>] process_timeout+0x0/0x5 Jul 13 16:27:34 bloodhound kernel: [<c0103aea>] common_interrupt+0x1a/0x20 Jul 13 16:27:34 bloodhound kernel: [<c012797c>] __do_softirq+0x2c/0x8a Jul 13 16:27:34 bloodhound kernel: [<c0105a17>] do_softirq+0x39/0x40 Jul 13 16:27:34 bloodhound kernel: ======================= Jul 13 16:27:34 bloodhound kernel: [<c0105912>] do_IRQ+0x53/0x85 Jul 13 16:27:34 bloodhound kernel: [<c0103aea>] common_interrupt+0x1a/0x20 Jul 13 16:27:34 bloodhound kernel: [<c0112592>] delay_pmtmr+0xb/0x13 Jul 13 16:27:34 bloodhound kernel: [<c0208779>] __delay+0x9/0xa Jul 13 16:27:34 bloodhound kernel: [<e08fc1cc>] start_ts_capture+0x14a/0x280 [budget_core] Jul 13 16:27:34 bloodhound kernel: [<e08fd475>] ttpci_budget_set_video_port+0xfd/0x1a8 [budget_core] Jul 13 16:27:34 bloodhound kernel: [<c011bbcd>] __wake_up_common+0x35/0x55 Jul 13 16:27:34 bloodhound kernel: [<e091a4c8>] ciintf_slot_shutdown+0x2d/0x31 [budget_ci] Jul 13 16:27:34 bloodhound kernel: [<e09a6d9b>] dvb_ca_en50221_slot_shutdown+0x5d/0xf5 [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<e09a776a>] dvb_ca_en50221_io_do_ioctl+0x116/0x151 [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<e099f5d8>] dvb_usercopy+0x93/0x102 [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<e099f0b3>] dvb_device_open+0x54/0xe8 [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<c0182c51>] chrdev_open+0x14c/0x36b Jul 13 16:27:34 bloodhound kernel: [<c01e9ec4>] file_alloc_security+0x29/0x7d Jul 13 16:27:34 bloodhound kernel: [<c0176019>] dentry_open+0xaf/0x1a5 Jul 13 16:27:34 bloodhound kernel: [<e09a77a5>] dvb_ca_en50221_io_ioctl+0x0/0x1d [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<e09a77bd>] dvb_ca_en50221_io_ioctl+0x18/0x1d [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<e09a7654>] dvb_ca_en50221_io_do_ioctl+0x0/0x151 [dvb_core] Jul 13 16:27:34 bloodhound kernel: [<c018de89>] do_ioctl+0x39/0x52 Jul 13 16:27:34 bloodhound kernel: [<c018df97>] vfs_ioctl+0x55/0x193 Jul 13 16:27:34 bloodhound kernel: [<c018e134>] sys_ioctl+0x5f/0x6f Jul 13 16:27:34 bloodhound kernel: [<c010392d>] syscall_call+0x7/0xb Jul 13 16:27:34 bloodhound kernel: handlers: Jul 13 16:27:34 bloodhound kernel: [<e08c70af>] (interrupt_hw+0x0/0x345 [saa7146]) Jul 13 16:27:34 bloodhound kernel: [<c02c4d70>] (usb_hcd_irq+0x0/0x57) Jul 13 16:27:35 bloodhound kernel: [<c02c4d70>] (usb_hcd_irq+0x0/0x57) Jul 13 16:27:35 bloodhound kernel: Disabling IRQ #11 Jul 13 16:27:39 bloodhound kernel: dvb_ca adaptor 0: PC card did not respond :( According to the stacktrace the last time it was in the dvb code was in start_ts_capture in budget_core.c. I believe its these lines... 113: saa7146_write(dev, MC2, (MASK_08 | MASK_24)); 114: mdelay(10); 115: 116: saa7146_write(dev, BASE_ODD3, 0); 117: saa7146_write(dev, BASE_EVEN3, 0); 118: saa7146_write(dev, PROT_ADDR3, TS_WIDTH * TS_HEIGHT); 119: saa7146_write(dev, BASE_PAGE3, budget->pt.dma | ME1 | 0x90); Why is there a 10 millisecond delay done there? How could it cause an NMI? Is it OK to comment out that line? I appreciate any help in tracking this issue down. Mike On 7/15/05, Michael Ditum <mrskensington@xxxxxxxxx> wrote: > We've managed to fix the issue and the card is now running quite > happily without any messages going to /var/log/messages > > We only modified a couple of lines, basically we comment out the line > that says it supports IRQ's so the polling section is reached and then > instead of directly calling the dvb_ca_en50221_read_data function we > wake the thread that calls it. > > I've attached the patch to the latest CVS drivers. > > On 7/14/05, Andrew de Quincey <adq_dvb@xxxxxxxxxxxxx> wrote: > > On Thursday 14 July 2005 15:10, Michael Ditum wrote: > > > ok we've done a bit more investigating... we enabled cam_debug for > > > dvb_core and looking at the output it comes up with the error message > > > in the dvb_ca_en50221_read_data function which is in dvb_ca_en50221.c. > > > > > > More specifically its on line 604 with the code... > > > > > > down_read(&ca->slot_info[slot].sem); > > > > > > As far as we can tell the read data function is being called by an > > > interrupt request handler (line 895 dvb_ca_en50221_frda_irq)... it > > > then calls down_read which tries to lock a semaphore which is already > > > locked and attempts to sleep until it becomes available. > > > > > > Another developer here believeds that you cannot sleep in a IRQ > > > handler so this looks to be the reason for the error... > > > > > > Does anyone have any ideas? > > > > That sounds very likely.... that code supports two mode of operation - > IRQ > > based and polling.. the last card I supported using it used polling so it > > sounds like the IRQ mode needs tweaked to work properly again. > > > >
