Bug 11121 (via-velocity:irq)

Latest working kernel version: 2.6.25.10
Earliest failing kernel version: 2.6.26

Marking this as a regression.

Created attachment 16888 [details]
2.6.26 Kernel Config

Created attachment 16890 [details]
do_irq_debug.diff

Created attachment 16891 [details]
via_velocity_registration_order.diff

is it reproducible?
does call trace looks always the same?
can you provide contents of /proc/interrupts and full dmesg output with do_irq_debug.diff patch?
does applying via_velocity_registration_order.diff change anything?

Created attachment 16895 [details]
cat /proc/interrupts

Created attachment 16896 [details]
full dmesg output with do_irq_debug.diff patch

the panic occurs when the system boots up with a down'ed interface, and when you manually try to bring it up with "ifconfig ethX up" the kernelpanic occurs
with the enable_irq32.... patch applied i cannot see changes

Created attachment 16897 [details]
dmesg output with via_velocity_registration_order.diff patch

Created attachment 16898 [details]
full dmesg with workaround

add kernel commandline "pci=noacpi"

ok, if i understand it correctly, velocity_open -> velocity_init_rd_ring -> velocity_rx_refill -> velocity_give_many_rx_descs -> writew
enables velocity interrupt, but ACPI IRQ routing maps it to the wrong IRQ handler (struct irq_desc->handle_irq is NULL)

so someone with ACPI knowledge should look at this bug.
maybe applying do_irq_debug_v2.diff patch will help narrow it...

Created attachment 16904 [details]
do_irq_debug_v2.diff

Can you please add full boot logs for the last working kernel and for the failing
kernel and acpidmp?

Also a bisect if you have time would be useful.

Created attachment 16905 [details]
full dmesg with do_irq_debug_v2.diff patch

Created attachment 16906 [details]
acpidump on kernel 2.6.26

Created attachment 16907 [details]
full dmesg on kernel 2.6.25.10 (works)

Created attachment 16908 [details]
acpidump on kernel  2.6.25.10 (no diff =>2.6.26)

Created attachment 16909 [details]
full dmesg with do_irq_debug_v2.diff patch and enabled acpi/device kernel debug

This problem goes away when the exact same kernel
is booted with "pci=noacpi"?

This is surprising, as ACPI's role here is
to return the IRQ number, and it returns 23, just
like the the working 2.6.25 and non pci=noacpi case.

I don't understand the /proc/interrupts in comment #7,
as they are in PIC mode, and the dmesg here,
even the pci=noacpi case are all in IOAPIC mode.

I too recommend a bisect.  start with drivers/net/via-velocity*

Created attachment 16911 [details]
cat /proc/interrupts with APIC

there is no problem when using "pci=noacpi" in the commandline with the exact same kernel

the interface functions also without "pci=noacpi" with the kernel version 2.6.25 (same config) 

i ve optimized the kernel config independently and noticed that the interfaces runs smoothly.
debug message ... disabled irq set...

i ve saved both config files and checked the difference
and i ve tested the most important settings but to my surprise the interface still worked
it is comprehensible that compiling on that pc is awful (1GHZ), especially with 18 complete rounds

Created attachment 16912 [details]
kernel config (kernel panic)

Created attachment 16913 [details]
kernel config (eth0 work with irq message)

status:

ifconfig eth0 up
irq 163, desc: c0401fe8, depth: 1, count: 0, unhandled: 0
->handle_irq():  c013010f, handle_bad_irq+0x0/0x199
->chip(): c0402d40, no_irq_chip+0x0/0x40
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ trap at vector a3
Velocity is AUTO mode

Here you have two NIC cards, eth0 for VIA Rhine II and eth1 for VIA Velocity. And more, when doing 'ifconfig eth0 up', the eth1's open method is called?


(In reply to comment #0)
> Latest working kernel version: 2.6.26
> Earliest failing kernel version: 2.6.25.10
> Distribution: Debian 4.1.1-21
> Hardware Environment: Via Epia SN (VT6130 chipset)
> Software Environment: gcc version 4.1.2
> Problem Description:
> 
> dmesg|grep eth0
> 
> eth0: VIA Rhine II at 0xfafff400, 00:40:63:f3:7b:d7, IRQ 23.
> eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
> 
> ifconfig eth0 up
> 
> BUG: unable to handle kernel NULL pointer dereference at 00000000
> IP: [<00000000>]
> *pde = 00000000
> Oops: 0000 [#1]
> Modules linked in:
> 
> Pid: 2646, comm: ifconfig Not tainted (2.6.26 #3)
> EIP: 0060:[<00000000>] EFLAGS: 00010016 CPU: 0
> EIP is at 0x0
> EAX: 000000a3 EBX: 000000a3 ECX: 000023a8 EDX: c045a188
> ESI: 00000000 EDI: f7d37be4 EBP: 000080d0 ESP: f760de5c
>  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Process ifconfig (pid: 2646, ti=f760c000 task=f7d13440 task.ti=f760c000)
> Stack: c01048f1 00001000 00001000 c0103a17 00001000 00000107 f7d37000
> 00001000
>        f7d37be4 000080d0 00000000 0000007b 0000007b 00000000 ffffff5c
>        c014c19d
>        00000060 00010216 f7d32380 00000000 f7118100 f738e000 c024e171
>        f7d32380
> Call Trace:
>  [<c01048f1>] do_IRQ+0x6a/0x7d
>  [<c0103a17>] common_interrupt+0x23/0x28
>  [<c014c19d>] __kmalloc+0x84/0x9a
>  [<c024e171>] velocity_init_td_ring+0x32/0xe1
>  [<c024f38e>] velocity_open+0x179/0x21b
>  [<c02db39d>] dev_open+0x63/0x93
>  [<c02da339>] dev_change_flags+0x92/0x13d
>  [<c0311510>] devinet_ioctl+0x230/0x528
>  [<c02d2642>] sock_ioctl+0x152/0x174
>  [<c02d24f0>] sock_ioctl+0x0/0x174
>  [<c0157146>] vfs_ioctl+0x16/0x48
>  [<c015735b>] do_vfs_ioctl+0x1e3/0x1f6
>  [<c033c56a>] do_page_fault+0x262/0x574
>  [<c015739a>] sys_ioctl+0x2c/0x42
>  [<c0103025>] sysenter_past_esp+0x6a/0x91
>  =======================
> Code:  Bad EIP value.
> EIP: [<00000000>] 0x0 SS:ESP 0068:f760de5c
> Kernel panic - not syncing: Fatal exception in interrupt
> 
> 
> 
> Steps to reproduce:
> ifconfig eth0 up
> 

the interface renamed at boot time (rc.S => in debian) eth0 <==> eth1

device: 'eth0': device_rename: renaming to 'eth0_rename'
device: 'eth1': device_rename: renaming to 'eth0'
device: 'eth0_rename': device_rename: renaming to 'eth1'



(In reply to comment #25)
> Here you have two NIC cards, eth0 for VIA Rhine II and eth1 for VIA Velocity.
> And more, when doing 'ifconfig eth0 up', the eth1's open method is called?
> (In reply to comment #0)
> > Latest working kernel version: 2.6.26
> > Earliest failing kernel version: 2.6.25.10
> > Distribution: Debian 4.1.1-21
> > Hardware Environment: Via Epia SN (VT6130 chipset)
> > Software Environment: gcc version 4.1.2
> > Problem Description:
> > 
> > dmesg|grep eth0
> > 
> > eth0: VIA Rhine II at 0xfafff400, 00:40:63:f3:7b:d7, IRQ 23.
> > eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
> > 
> > ifconfig eth0 up
> > 
> > BUG: unable to handle kernel NULL pointer dereference at 00000000
> > IP: [<00000000>]
> > *pde = 00000000
> > Oops: 0000 [#1]
> > Modules linked in:
> > 
> > Pid: 2646, comm: ifconfig Not tainted (2.6.26 #3)
> > EIP: 0060:[<00000000>] EFLAGS: 00010016 CPU: 0
> > EIP is at 0x0
> > EAX: 000000a3 EBX: 000000a3 ECX: 000023a8 EDX: c045a188
> > ESI: 00000000 EDI: f7d37be4 EBP: 000080d0 ESP: f760de5c
> >  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> > Process ifconfig (pid: 2646, ti=f760c000 task=f7d13440 task.ti=f760c000)
> > Stack: c01048f1 00001000 00001000 c0103a17 00001000 00000107 f7d37000
> 00001000
> >        f7d37be4 000080d0 00000000 0000007b 0000007b 00000000 ffffff5c
> c014c19d
> >        00000060 00010216 f7d32380 00000000 f7118100 f738e000 c024e171
> f7d32380
> > Call Trace:
> >  [<c01048f1>] do_IRQ+0x6a/0x7d
> >  [<c0103a17>] common_interrupt+0x23/0x28
> >  [<c014c19d>] __kmalloc+0x84/0x9a
> >  [<c024e171>] velocity_init_td_ring+0x32/0xe1
> >  [<c024f38e>] velocity_open+0x179/0x21b
> >  [<c02db39d>] dev_open+0x63/0x93
> >  [<c02da339>] dev_change_flags+0x92/0x13d
> >  [<c0311510>] devinet_ioctl+0x230/0x528
> >  [<c02d2642>] sock_ioctl+0x152/0x174
> >  [<c02d24f0>] sock_ioctl+0x0/0x174
> >  [<c0157146>] vfs_ioctl+0x16/0x48
> >  [<c015735b>] do_vfs_ioctl+0x1e3/0x1f6
> >  [<c033c56a>] do_page_fault+0x262/0x574
> >  [<c015739a>] sys_ioctl+0x2c/0x42
> >  [<c0103025>] sysenter_past_esp+0x6a/0x91
> >  =======================
> > Code:  Bad EIP value.
> > EIP: [<00000000>] 0x0 SS:ESP 0068:f760de5c
> > Kernel panic - not syncing: Fatal exception in interrupt
> > 
> > 
> > 
> > Steps to reproduce:
> > ifconfig eth0 up
> > 

Pleaase re-open against a current kernel if still seen