| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: free_irq_vector on ia64
On Thu, 2007-08-30 at 18:48 +0800, Herbert Xu wrote:
> Hi Alex:
>
> I was looking at an ia64 bug report and noticed that we don't
> actually free IRQs in the free_irq_vector hypercall. This
> would eventually lead to alloc_irq_vector failing. Unless I'm
> mistaken something like calling pci_disable_device and
> pci_enable_device can lead to this situation.
>
> So I'm wondering what the original problem was and how could
> we resolve it without leaking the IRQ. Any ideas?
Hi Herbert,
I don't think we ever investigated this any further, though there's
obviously something wrong there. I believe you're referring to this
cset:
http://xenbits.xensource.com/xen-unstable.hg?rev/968caf47b548
Unfortunately, the comment is still true. This is fairly simply to
reproduce, hide a PCI device from dom0 using something like
pciback.hide=(0000:01:02.1) on the dom0 append line (this is hiding
function 1 or a 2 port/function e1000 card). Simply boot dom0, reboot,
badness...
Unable to handle kernel paging request at virtual address 0000007366627375
reboot[2703]: Oops 8813272891392 [1]
Modules linked in:
Pid: 2703, CPU 1, comm: reboot
psr : 00001010085a6010 ifs : 800000000000038a ip : [<a0000001000acab0>] Not
tainted
ip is at notifier_call_chain+0x30/0xc0
unat: 0000000000000000 pfs : 400000000000038a rsc : 0000000000000007
rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000055a959
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a0000001000aed00 b6 : a000000100018610 b7 : a000000100018570
f6 : 000000000000000000000 f7 : 000000000000000000000
f8 : 000000000000000000000 f9 : 000000000000000000000
f10 : 000000000000000000000 f11 : 000000000000000000000
r1 : a0000001011225a0 r2 : 4000000000000792 r3 : a000000100f3e368
r8 : 0000007366627375 r9 : 60000fffff4bfc90 r10 : 0000000000000000
r11 : 0000000000000008 r12 : e0000001b7d57d30 r13 : e0000001b7d50000
r14 : e0000001be05a880 r15 : 0000000100000000 r16 : 0000000000000000
r17 : 0000000001234567 r18 : 0000000000200000 r19 : 0000000000000008
r20 : 2000000000244200 r21 : 0009804c8a70033f r22 : e0000001b7d50f70
r23 : 60000fff7fffc0c8 r24 : 0000000000000000 r25 : 0000000000000000
r26 : c00000000000010a r27 : 0000000000000000 r28 : fffffffffff00031
r29 : 00001213085a6010 r30 : 0000000000000000 r31 : a000000100d0b080
Call Trace:
[<a00000010001d520>] show_stack+0x40/0xa0
sp=e0000001b7d578e0 bsp=e0000001b7d511a8
[<a00000010001e180>] show_regs+0x840/0x880
sp=e0000001b7d57ab0 bsp=e0000001b7d51150
[<a000000100042900>] die+0x1c0/0x380
sp=e0000001b7d57ab0 bsp=e0000001b7d51108
[<a000000100066970>] ia64_do_page_fault+0x870/0x9a0
sp=e0000001b7d57ad0 bsp=e0000001b7d510b8
[<a000000100069140>] xen_leave_kernel+0x0/0x3e0
sp=e0000001b7d57b60 bsp=e0000001b7d510b8
[<a0000001000acab0>] notifier_call_chain+0x30/0xc0
sp=e0000001b7d57d30 bsp=e0000001b7d51068
[<a0000001000aed00>] blocking_notifier_call_chain+0x40/0x80
sp=e0000001b7d57d30 bsp=e0000001b7d51030
[<a0000001000afb10>] kernel_restart+0x30/0x120
sp=e0000001b7d57d30 bsp=e0000001b7d51010
[<a0000001000afff0>] sys_reboot+0x3b0/0x480
sp=e0000001b7d57d30 bsp=e0000001b7d50f90
[<a000000100014560>] ia64_ret_from_syscall+0x0/0x40
sp=e0000001b7d57e30 bsp=e0000001b7d50f90
[<a0000000000108e0>] __kernel_syscall_via_break+0x0/0x20
sp=e0000001b7d58000 bsp=e0000001b7d50f90
/etc/rc6.d/S90reboot: line 17: 2703 Segmentation fault reboot -d -f -i
I'd guess this is some kind of double free that we need to track down.
Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home