IRQ problem on cobalt / 2.6.6

IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 5461 bytes --]

hi folks, 

getting the below when loading the dvb budget_ci module. it disables IRQ 
#23 which is attached to the card, rendering it useless. i asked the 
same question over there and none of them suspect it to be a DVB 
problem. some esoteric pci bug perhaps?

lspci -vv
0000:00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 
01)
        Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1011
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (3750ns min, 9500ns max)
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at 12080800 (32-bit, non-prefetchable)

cat /proc/interrupts
           CPU0
  2:          0          XT-PIC  cascade
 14:     321895          XT-PIC  ide0
 18:   82942617            MIPS  timer
 19:     131702            MIPS  eth0
 21:        345            MIPS  serial
 22:          0            MIPS  cascade
 23:     100002            MIPS  saa7146 (0)

ERR:          0

 dmesg | ksymoops
ksymoops 2.4.9 on mips 2.6.6-mipscvs-20040510.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.6-mipscvs-20040510/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Call Trace: [<80084624>]  [<8008461c>]  [<80084720>]  [<800b179c>]  
[<800b1788>]  [<80084a78>]  [<800b1af8>]  [<800826d0>]  [<800ac718>]  
[<80082ec0>]  [<801593c0>]  [<800ac7f4>]  [<80084b18>]  [<800ac6f8>]  
[<80084578>]  [<80084578>]  [<800ac7f4>]  [<80084b18>]  [<80082ec0>]  
[<800826d0>]  [<80082ec0>]  [<801594a4>]  [<801593c0>]  [<80085468>]  
[<80085480>]  [<8019c624>]  [<8019c610>]  [<c001b570>]  [<80084bec>]  
[<8015bff8>]  [<800ce3ec>]  [<800ce3ec>]  [<c001bc24>]  [<80126eb8>]  
[<8015d338>]  [<c001b544>]  [<801780e0>]  [<8015d3a0>]  [<8015d7b4>]  
[<8015d408>]  [<80153bf4>]  [<80178eb0>]  [<80154140>]  [<80154018>]  
[<80154258>]  [<80178fec>]  [<80179284>]  [<80179608>]  [<800a83e4>]  
[<800a8264>]  [<8015d684>]  [<800a81d4>]  [<c001c298>]  [<c001c288>]  
[<c002a020>]  [<800c2b98>]  [<800c2b40>]  [<800e7ef0>]  [<8008be88>]
[<c001b570>]
Warning (Oops_read): Code line not seen, dumping what data is available


Trace; 80084624 <__report_bad_irq+48/8c>
Trace; 8008461c <__report_bad_irq+40/8c>
Trace; 80084720 <note_interrupt+88/d0>
Trace; 800b179c <update_process_times+40/54>
Trace; 800b1788 <update_process_times+2c/54>
Trace; 80084a78 <do_IRQ+110/1dc>
Trace; 800b1af8 <do_timer+78/144>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 800ac718 <__do_softirq+68/ec>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 801593c0 <memset+0/1c>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80084b18 <do_IRQ+1b0/1dc>
Trace; 800ac6f8 <__do_softirq+48/ec>
Trace; 80084578 <handle_IRQ_event+6c/d0>
Trace; 80084578 <handle_IRQ_event+6c/d0>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80084b18 <do_IRQ+1b0/1dc>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 801594a4 <memset_partial+48/6c>
Trace; 801593c0 <memset+0/1c>
Trace; 80085468 <setup_irq+134/1b0>
Trace; 80085480 <setup_irq+14c/1b0>
Trace; 8019c624 <pcibios_set_master+8c/9c>
Trace; 8019c610 <pcibios_set_master+78/9c>
Trace; c001b570 <__crc_bio_map_user+64b64/130ac7>
Trace; 80084bec <request_irq+a8/e4>
Trace; 8015bff8 <pci_set_master+54/64>
Trace; 800ce3ec <kmem_cache_alloc+0/98>
Trace; 800ce3ec <kmem_cache_alloc+0/98>
Trace; c001bc24 <__crc_bio_map_user+65218/130ac7>
Trace; 80126eb8 <sysfs_create+7c/d0>
Trace; 8015d338 <pci_device_probe_static+50/80>
Trace; c001b544 <__crc_bio_map_user+64b38/130ac7>
Trace; 801780e0 <get_device+20/34>
Trace; 8015d3a0 <__pci_device_probe+38/70>
Trace; 8015d7b4 <pci_dev_get+20/38>
Trace; 8015d408 <pci_device_probe+30/5c>
Trace; 80153bf4 <create_dir+3c/68>
Trace; 80178eb0 <bus_match+4c/84>
Trace; 80154140 <kobject_add+9c/fc>
Trace; 80154018 <kobject_init+3c/5c>
Trace; 80154258 <kobject_set_name+50/104>
Trace; 80178fec <driver_attach+50/9c>
Trace; 80179284 <bus_add_driver+84/b0>
Trace; 80179608 <driver_register+34/40>
Trace; 800a83e4 <printk+210/280>
Trace; 800a8264 <printk+90/280>
Trace; 8015d684 <pci_register_driver+70/a0>
Trace; 800a81d4 <printk+0/280>
Trace; c001c298 <__crc_bio_map_user+6588c/130ac7>
Trace; c001c288 <__crc_bio_map_user+6587c/130ac7>
Trace; c002a020 <__crc_bio_map_user+73614/130ac7>
Trace; 800c2b98 <sys_init_module+2bc/4f0>
Trace; 800c2b40 <sys_init_module+264/4f0>
Trace; 800e7ef0 <sys_close+d4/120>
Trace; 8008be88 <stack_done+24/40>
Trace; c001b570 <__crc_bio_map_user+64b64/130ac7>


2 warnings and 1 error issued.  Results may not be reliable.


cheers,
Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

Kieran Fulke wrote:

>hi folks, 
>
>getting the below when loading the dvb budget_ci module. it disables IRQ 
>#23 which is attached to the card, rendering it useless. i asked the 
>same question over there and none of them suspect it to be a DVB 
>problem. some esoteric pci bug perhaps?
>
>  
>
Have you tried any other hardware in the slot, PCI network card perhaps ?

P.

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Fri, May 14, 2004 at 08:43:44AM +0100, Peter Horton wrote:

> Have you tried any other hardware in the slot, PCI network card perhaps ?
> 
> P.

yeah. adding cards like a tulip network card, linksys wmp11 wireless card. even a 
wintv pci (analogue) card all work ;

0000:00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)
        Subsystem: Kingston Technologies: Unknown device 0001
        Flags: bus master, medium devsel, latency 64, IRQ 23
        I/O ports at 1080 [size=288M]
        Memory at 120c0400 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at 00040000 [disabled]

cat /proc/interrupts
           CPU0
  2:          0          XT-PIC  cascade
 14:      27636          XT-PIC  ide0
 18:     435142            MIPS  timer
 19:        696            MIPS  eth0
 20:          7            MIPS  eth2
 21:        302            MIPS  serial
 22:          0            MIPS  cascade
 23:     100002            MIPS  eth1


it just seems to be the DVB card that the pci code doesnt like, for some reason ..

all ideas warmly received ;)

Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Johannes Stezenbach]

On Sun, May 16, 2004 at 12:36:22PM +0100, Kieran Fulke wrote:
> On Fri, May 14, 2004 at 08:43:44AM +0100, Peter Horton wrote:
> 
> > Have you tried any other hardware in the slot, PCI network card perhaps ?
> > 
> > P.
> 
> yeah. adding cards like a tulip network card, linksys wmp11 wireless card. even a 
> wintv pci (analogue) card all work ;
...
> it just seems to be the DVB card that the pci code doesnt like, for some reason ..
> 
> all ideas warmly received ;)

Let me add some information from your posts to linux-dvb and from
the driver source.

I would appreciate it if someone could look it over (full source
is in linux/drivers/media/common/saa7146_core.c). The driver is
known to work on a variety of platforms, including one TX49 based
development system (last tested a few months back, though).


From your first posting:

   PCI: Setting latency timer of device 0000:00:0a.0 to 64
   irq 23: nobody cared!
   Call Trace: [snipped]
   handlers:
   [<c004b570>]
   Disabling IRQ #23
   saa7146: found saa7146 @ mem b2080800 (revision 1, irq 23) (0x13c2,0x1011).

Second try with debug enabled:

   saa7146: saa7146_register_extension(): ext:c001efb0
   saa7146: register extension 'budget_ci dvb'.
   saa7146: saa7146_init_one(): pci:83fdac00
   irq 23: nobody cared!


saa7146_init_one() does the following:
        /* disable all irqs */
	saa7146_write(dev, IER, 0);
	...
        if (request_irq(dev->pci->irq, interrupt_hw, SA_SHIRQ | SA_INTERRUPT,
                        dev->name, dev))
        {error...}
        ...
        INFO(("found saa7146 @ mem %p (revision %d, irq %d) (0x%04x,0x%04x).\n", ...));

interrupt_hw() does:
        /* read out the interrupt status register */
        isr = saa7146_read(dev, ISR);

        /* is this our interrupt? */
        if ( 0 == isr ) {
                /* nope, some other device */
                return IRQ_NONE;
        }
        ...
        return IRQ_HANDLED;


In essence, I believe something other than the saa7146 must be asserting irq 23.
Or is it possible that a bug in the PCI init stuff in saa7146_core.c can
cause this? Any hints how we could debug this would be welcome.


Johannes

Re: IRQ problem on cobalt / 2.6.6

[Johannes Stezenbach]

On Sun, May 16, 2004 at 12:36:22PM +0100, Kieran Fulke wrote:
> On Fri, May 14, 2004 at 08:43:44AM +0100, Peter Horton wrote:
> 
> > Have you tried any other hardware in the slot, PCI network card perhaps ?
> > 
> > P.
> 
> yeah. adding cards like a tulip network card, linksys wmp11 wireless card. even a 
> wintv pci (analogue) card all work ;
...
> it just seems to be the DVB card that the pci code doesnt like, for some reason ..
> 
> all ideas warmly received ;)

Let me add some information from your posts to linux-dvb and from
the driver source.

I would appreciate it if someone could look it over (full source
is in linux/drivers/media/common/saa7146_core.c). The driver is
known to work on a variety of platforms, including one TX49 based
development system (last tested a few months back, though).

Re: IRQ problem on cobalt / 2.6.6

[Ralf Baechle]

On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote:

> In essence, I believe something other than the saa7146 must be asserting
> irq 23.  Or is it possible that a bug in the PCI init stuff in
> saa7146_core.c can
> cause this? Any hints how we could debug this would be welcome.

arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect.  It connects
CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare
interrupt already uses this bit.

Sharing the timer interrupt with something else isn't impossible but seems
a less than bright thing to do.  Somebody with production hw to test
should compare this interrupt dispatch function with old working code
from 2.2 or 2.4 ...

  Ralf

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Sun, May 16, 2004 at 07:04:45PM +0200, Ralf Baechle wrote:

> 
> Sharing the timer interrupt with something else isn't impossible but seems
> a less than bright thing to do.  Somebody with production hw to test
> should compare this interrupt dispatch function with old working code
> from 2.2 or 2.4 ...
> 

what exactly do you mean by test? as far as the dvb drivers go, they 
work without any problem (with in the same box / hardware) under 2.4. if 
you can suggest some test cases / methods, i'll happily run them ...

regards,
Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Johannes Stezenbach]

On Sun, May 16, 2004 at 07:04:45PM +0200, Ralf Baechle wrote:
> On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote:
> 
> > In essence, I believe something other than the saa7146 must be asserting
> > irq 23.  Or is it possible that a bug in the PCI init stuff in
> > saa7146_core.c can
> > cause this? Any hints how we could debug this would be welcome.
> 
> arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect.  It connects
> CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare
> interrupt already uses this bit.
> 
> Sharing the timer interrupt with something else isn't impossible but seems
> a less than bright thing to do.  Somebody with production hw to test
> should compare this interrupt dispatch function with old working code
> from 2.2 or 2.4 ...

Sorry if I snipped too much from Kieran's mail. He reported
a tulip network card works in the same PCI slot, and it uses
irq 23, too.

But this one from Kieran's mail looks dubious:

> > cat /proc/interrupts
> >            CPU0
> >   2:          0          XT-PIC  cascade
> >  14:      27636          XT-PIC  ide0
> >  18:     435142            MIPS  timer
> >  19:        696            MIPS  eth0
> >  20:          7            MIPS  eth2
> >  21:        302            MIPS  serial
> >  22:          0            MIPS  cascade
> >  23:     100002            MIPS  eth1

100002 is just where note_interrupt() disables an unhandled irq, so
maybe Kieran's report that the tulip card works was wrong?


Johannes

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Sun, May 16, 2004 at 07:21:43PM +0200, Johannes Stezenbach wrote:

> 
> 100002 is just where note_interrupt() disables an unhandled irq, so
> maybe Kieran's report that the tulip card works was wrong?
> 

interesting. the card pulled an ip address from dhcp happily enough, but i'll see if it'll 
pull data back and forth. 

Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 4009 bytes --]

On Sun, May 16, 2004 at 07:21:43PM +0200, Johannes Stezenbach wrote:

> > >  23:     100002            MIPS  eth1
> 
> 100002 is just where note_interrupt() disables an unhandled irq, so
> maybe Kieran's report that the tulip card works was wrong?
> 

yup. please excuse me, i was obviously typing out of my arse (or not 
testing 'thoroughly' enough ...). anyway, the following turns up on 
running 'dhcpcd eth1' (tulip card in pci slot);

ksymoops 2.4.9 on mips 2.6.6-mipscvs-20040510.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.6-mipscvs-20040510/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Call Trace: [<80084624>]  [<8008461c>]  [<80084720>]  [<800826d0>]  
[<80084a78>]  [<80082ec0>]  [<800826d0>]  [<80082ec0>]  [<800ec230>]  
[<800ac7f4>]  [<800ac6f8>]  [<80084578>]  [<800ac7f4>]  [<80084b18>]  
[<800826d0>]  [<8012ea48>]  [<80082ec0>]  [<800b179c>]  [<800b1788>]  
[<800ac7f4>]  [<80085468>]  [<80085480>]  [<c0051270>]  [<80084bec>]  
[<80082ec0>]  [<c0053db8>]  [<800dcf4c>]  [<801a684c>]  [<801ac4e4>]  
[<800d7924>]  [<801a85fc>]  [<801a66c0>]  [<801e9ae0>]  [<801e9958>]  
[<800d7c44>]  [<80091b50>]  [<801ec8c4>]  [<801fd878>]  [<801fd888>]  
[<8019e27c>]  [<8019e1c4>]  [<8019dc9c>]  [<800ff3bc>]  [<800ff194>]  
[<8019e4bc>]  [<8008be88>]
[<c0051270>]
Warning (Oops_read): Code line not seen, dumping what data is available


Trace; 80084624 <__report_bad_irq+48/8c>
Trace; 8008461c <__report_bad_irq+40/8c>
Trace; 80084720 <note_interrupt+88/d0>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 80084a78 <do_IRQ+110/1dc>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800ec230 <bh_lru_install+180/1a4>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 800ac6f8 <__do_softirq+48/ec>
Trace; 80084578 <handle_IRQ_event+6c/d0>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80084b18 <do_IRQ+1b0/1dc>
Trace; 800826d0 <cobalt_irq+150/180>
Trace; 8012ea48 <ext3_getblk+d0/298>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; 800b179c <update_process_times+40/54>
Trace; 800b1788 <update_process_times+2c/54>
Trace; 800ac7f4 <do_softirq+58/8c>
Trace; 80085468 <setup_irq+134/1b0>
Trace; 80085480 <setup_irq+14c/1b0>
Trace; c0051270 <__crc_bio_map_user+9a864/130ac7>
Trace; 80084bec <request_irq+a8/e4>
Trace; 80082ec0 <ret_from_exception+0/0>
Trace; c0053db8 <__crc_bio_map_user+9d3ac/130ac7>
Trace; 800dcf4c <pte_chain_alloc+a4/c8>
Trace; 801a684c <dev_open+94/138>
Trace; 801ac4e4 <dev_mc_upload+58/64>
Trace; 800d7924 <do_no_page+43c/510>
Trace; 801a85fc <dev_change_flags+70/154>
Trace; 801a66c0 <dev_load+24/a0>
Trace; 801e9ae0 <devinet_ioctl+30c/7cc>
Trace; 801e9958 <devinet_ioctl+184/7cc>
Trace; 800d7c44 <handle_mm_fault+f0/278>
Trace; 80091b50 <do_page_fault+170/370>
Trace; 801ec8c4 <inet_ioctl+8c/e8>
Trace; 801fd878 <packet_ioctl+18c/1b0>
Trace; 801fd888 <packet_ioctl+19c/1b0>
Trace; 8019e27c <__sock_create+1a4/384>
Trace; 8019e1c4 <__sock_create+ec/384>
Trace; 8019dc9c <sock_ioctl+418/464>
Trace; 800ff3bc <sys_ioctl+254/2d8>
Trace; 800ff194 <sys_ioctl+2c/2d8>
Trace; 8019e4bc <sys_socket+24/48>
Trace; 8008be88 <stack_done+24/40>
Trace; c0051270 <__crc_bio_map_user+9a864/130ac7>


2 warnings and 1 error issued.  Results may not be reliable.


regards,
kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

Ralf Baechle wrote:

>On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote:
>
>  
>
>>In essence, I believe something other than the saa7146 must be asserting
>>irq 23.  Or is it possible that a bug in the PCI init stuff in
>>saa7146_core.c can
>>cause this? Any hints how we could debug this would be welcome.
>>    
>>
>
>arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect.  It connects
>CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare
>interrupt already uses this bit.
>
>Sharing the timer interrupt with something else isn't impossible but seems
>a less than bright thing to do.  Somebody with production hw to test
>should compare this interrupt dispatch function with old working code
>from 2.2 or 2.4 ...
>
>  
>

I've got no hardware here but the code looks roughly similiar

As the Cobalt's use Galileo timer 0 for clock interrupts we could use 
Galileo rather than count/compare for the HPT.

Precision would be 50MHz rather than 125MHz but that shouldn't be a 
problem :-)

P.

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Mon, May 17, 2004 at 09:40:33AM +0100, Peter Horton wrote:

> 
> I've got no hardware here but the code looks roughly similiar
> 
> As the Cobalt's use Galileo timer 0 for clock interrupts we could use 
> Galileo rather than count/compare for the HPT.
> 
> Precision would be 50MHz rather than 125MHz but that shouldn't be a 
> problem :-)
> 

is there any (uncomplicated) way of forcing the machine to assign a 
different IRQ to its single pci slot?

Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

Kieran Fulke wrote:

>On Mon, May 17, 2004 at 09:40:33AM +0100, Peter Horton wrote:
>
>  
>
>>I've got no hardware here but the code looks roughly similiar
>>
>>As the Cobalt's use Galileo timer 0 for clock interrupts we could use 
>>Galileo rather than count/compare for the HPT.
>>
>>Precision would be 50MHz rather than 125MHz but that shouldn't be a 
>>problem :-)
>>
>>    
>>
>
>is there any (uncomplicated) way of forcing the machine to assign a 
>different IRQ to its single pci slot?
>
>  
>
It's hard wired.

P.

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Mon, May 17, 2004 at 12:57:57PM +0100, Peter Horton wrote:

> >
> It's hard wired.
> 

that is quite inconvenient. 
so has that timer code changed a lot from 2.4 -> 2.6 ? i've gone back to 
2.4 in the meantime, which has its own issues but works for me .....

Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

Kieran Fulke wrote:

>On Mon, May 17, 2004 at 12:57:57PM +0100, Peter Horton wrote:
>
>  
>
>>It's hard wired.
>>
>>    
>>
>
>that is quite inconvenient. 
>so has that timer code changed a lot from 2.4 -> 2.6 ? i've gone back to 
>2.4 in the meantime, which has its own issues but works for me .....
>
>  
>
I'll have a look when I get home.

P.

Re: IRQ problem on cobalt / 2.6.6

[Stuart Longland]

Kieran Fulke wrote:
> hi folks, 
> 
> getting the below when loading the dvb budget_ci module. it disables IRQ 
> #23 which is attached to the card, rendering it useless. i asked the 
> same question over there and none of them suspect it to be a DVB 
> problem. some esoteric pci bug perhaps?
> 

If it's any help... I've had similar issues trying to use an Adaptec 
AHA-2940AU PCI SCSI card in a Gateway Microserver running Linux 2.6.[56] 
(not sure which one exactly...).  I'm now running Linux 2.4.26 quite 
happily (the box is being used as a fileserver for LANs), but I can put 
2.6.6 back on if the debugging info would be of any use.

-- 
+-------------------------------------------------------------+
| Stuart Longland           stuartl at longlandclan.hopto.org |
| Brisbane Mesh Node: 719             http://stuartl.cjb.net/ |
| I haven't lost my mind - it's backed up on a tape somewhere |
| Atomic Linux Project    <--->    http://atomicl.berlios.de/ |
+-------------------------------------------------------------+

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

On Thu, May 13, 2004 at 07:30:59PM +0100, Kieran Fulke wrote:
> 
> getting the below when loading the dvb budget_ci module. it disables IRQ 
> #23 which is attached to the card, rendering it useless. i asked the 
> same question over there and none of them suspect it to be a DVB 
> problem. some esoteric pci bug perhaps?
> 

Not quite so esoteric :-)

Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in
include/asm/cobalt/cobalt.h.

P.

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

On Tue, May 18, 2004 at 08:34:39AM +0100, Peter Horton wrote:

> 
> Not quite so esoteric :-)
> 
> Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in
> include/asm/cobalt/cobalt.h.
> 

that looks embarrassingly simple. building a new kernel now. if only 
these things were a bit zippier ...

Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Tue, May 18, 2004 at 08:34:39AM +0100, Peter Horton wrote:

> 
> Not quite so esoteric :-)
> 
> Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in
> include/asm/cobalt/cobalt.h.
> 

alas, no joy.

<snip-snip>

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
    ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
spurious 8259A interrupt: IRQ9.

cheers,
Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Tue, May 18, 2004 at 09:59:14PM +0100, Kieran Fulke wrote:

> 
> <snip-snip>
> 
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with 
> idebus=xx
> VP_IDE: IDE controller at PCI slot 0000:00:09.1
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
>     ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio
>     ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
> spurious 8259A interrupt: IRQ9.
> 

i should also mention that the boot process stops at this point.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

On Tue, May 18, 2004 at 09:59:14PM +0100, Kieran Fulke wrote:
> On Tue, May 18, 2004 at 08:34:39AM +0100, Peter Horton wrote:
> 
> > 
> > Not quite so esoteric :-)
> > 
> > Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in
> > include/asm/cobalt/cobalt.h.
> > 
> 
> alas, no joy.
> 
> <snip-snip>
> 
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with 
> idebus=xx
> VP_IDE: IDE controller at PCI slot 0000:00:09.1
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
>     ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio
>     ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
> spurious 8259A interrupt: IRQ9.
> 

That's strange, it worked here.

Did you a clean build ?

P.

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1.1: Type: text/plain, Size: 321 bytes --]

On Tue, May 18, 2004 at 10:12:46PM +0100, Peter Horton wrote:

> 
> That's strange, it worked here.
> 
> Did you a clean build ?
> 

yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made 
the change to include/asm/cobalt/cobalt.h you suggested. kernel 
.config attached ..

Kieran.





[-- Attachment #1.2: .config.gz --]
[-- Type: application/octet-stream, Size: 4360 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

On Tue, May 18, 2004 at 10:18:10PM +0100, Kieran Fulke wrote:
> On Tue, May 18, 2004 at 10:12:46PM +0100, Peter Horton wrote:
> 
> > 
> > That's strange, it worked here.
> > 
> > Did you a clean build ?
> > 
> 
> yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made 
> the change to include/asm/cobalt/cobalt.h you suggested. kernel 
> .config attached ..
> 

Does this patch fix it ?

P.

--- linux.cvs/arch/mips/cobalt/irq.c	2003-11-13 14:30:45.000000000 +0000
+++ linux.pdh/arch/mips/cobalt/irq.c	2004-05-18 22:35:32.000000000 +0100
@@ -82,11 +83,15 @@
 	}
 
 	if (pending & CAUSEF_IP7) {			/* int 23 */
-		do_IRQ(COBALT_QUBE_SLOT_IRQ, regs);
+		do_IRQ(23, regs);
 		return;
 	}
 }

Re: IRQ problem on cobalt / 2.6.6

[Kumba]

Kieran Fulke wrote:

> yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made 
> the change to include/asm/cobalt/cobalt.h you suggested. kernel 
> .config attached ..
> 
> Kieran.

Just to rule out a few things, try disabling the following options in 
your .config:

CONFIG_IDE_TASK_IOCTL (IDE Taskfile Access)
CONFIG_IDE_TASKFILE_IO (IDE Taskfile IO)

CONFIG_TULIP_MWI (New bus configuration)
CONFIG_TULIP_MMIO (Use PCI shared mem for NIC registers)
CONFIG_TULIP_NAPI (Use NAPI RX polling)
CONFIG_TULIP_NAPI_HW_MITIGATION (Use Interrupt Mitigation)


Taskfile access is, afaict, needed only if you're doing disk forensics 
or such.  The new taskfile IO code hung up on me a few times on Cobalt 
when I was initially testing some of Peter's 2.6.x patches, and as such, 
I haven't cut it on since then.

Tulip, I don't recall which, but I *think* one of them also caused me 
some kind of an issue, I'm unsure if it was a hang or something else. In 
either case, I left them as is.

See if turning those off does anything different.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: IRQ problem on cobalt / 2.6.6

[Kieran Fulke]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On Tue, May 18, 2004 at 10:38:10PM +0100, Peter Horton wrote:

> 
> Does this patch fix it ?
> 
> P.
> 
> --- linux.cvs/arch/mips/cobalt/irq.c	2003-11-13 14:30:45.000000000 +0000
> +++ linux.pdh/arch/mips/cobalt/irq.c	2004-05-18 22:35:32.000000000 +0100
> @@ -82,11 +83,15 @@
>  	}
>  
>  	if (pending & CAUSEF_IP7) {			/* int 23 */
> -		do_IRQ(COBALT_QUBE_SLOT_IRQ, regs);
> +		do_IRQ(23, regs);
>  		return;
>  	}
>  }

Aha. that seems to work now. i can certainly now tune the card in and do 
stuff [tm] with it. thanks for the help.

 cat /proc/interrupts
           CPU0
  2:          0          XT-PIC  cascade
  9:       4134          XT-PIC  saa7146 (0)
 14:      27964          XT-PIC  ide0
 18:     711618            MIPS  timer
 19:      11311            MIPS  eth0
 21:        288            MIPS  serial
 22:          0            MIPS  cascade

0000:00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 
01)
        Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1011
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at 12080800 (32-bit, non-prefetchable)


cheers,
Kieran.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IRQ problem on cobalt / 2.6.6

[Maciej W. Rozycki]

On Tue, 18 May 2004, Kieran Fulke wrote:

> alas, no joy.
[...]
> VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
>     ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio
>     ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
> spurious 8259A interrupt: IRQ9.

 Hmm, interesting.  As the 8259A can only signal IRQ7 and possibly IRQ15
as spurious interrupts, this smells like a bug in 8259A handlers,
regardless of system-specific problems you have.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: IRQ problem on cobalt / 2.6.6

[Peter Horton]

Maciej W. Rozycki wrote:

>On Tue, 18 May 2004, Kieran Fulke wrote:
>
>  
>
>>alas, no joy.
>>    
>>
>[...]
>  
>
>>VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
>>    ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio
>>    ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
>>spurious 8259A interrupt: IRQ9.
>>    
>>
>
> Hmm, interesting.  As the 8259A can only signal IRQ7 and possibly IRQ15
>as spurious interrupts, this smells like a bug in 8259A handlers,
>regardless of system-specific problems you have.
>
>  
>
We were getting interrupt 23 and calling do_IRQ() with a value of 9 (a 
bug, obviously). Interrupt 9 is masked so we get a "spurious 8259A 
interrupt" message.

P.