similar to: where does do_IRQ() be called

Is *.text 1 *the same as *.section*??? .text 1 occurs in entry.S Please tell me what it means? Furquan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I setup a CentOS 6 server to use with KVM/QEMU, and I am getting the following error a good bit, granted it doesn't seem to be causing any trouble. I figured I would post and see if anyone has any ideas on the issue, or if I can just dismiss it. If I look at my logging/dmesg, I see: do_IRQ: 19.217 No irq handler for vector (irq -1) do_IRQ: 3.178 No irq handler for vector (irq -1) do_IRQ:

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

(I accidently (cross) posted this also in the xen-bugs mailing list. This wasn''t my intention. Sorry for that) Hi, I have two kernels vmlinuz-2.6.32-5-amd64 vmlinuz-2.6.32-5-xen-amd64 As you can see, distributions are the same, the latter differs by loading xen stuff. When booting the xen kernel (vmlinuz-2.6.32-5-xen-amd64) I noticed a problem which does not occur in the non

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

Here is an slightly updated version of the paravirt_ops patch. If your comments and criticism were welcome before, now it's even more! There are some issues that are _not_ addressed in this revision, and here are the causes: * split debugreg into multiple functions, suggested by Andi: - Me and jsfg agree that introducing more pvops (specially 14!) is not worthwhile. So, although we do

This is hopefully the last iteration of the pvops64 patch. >From the last version, we have only one change, which is include/asm-x86_64/processor.h: There were still one survivor in raw asm. Also, git screwed me up for some reason, and the 25th patch was missing the new files, paravirt.{c,h}. (although I do remember having git-add'ed it, but who knows...) Andrew, could you please push it

This is hopefully the last iteration of the pvops64 patch. >From the last version, we have only one change, which is include/asm-x86_64/processor.h: There were still one survivor in raw asm. Also, git screwed me up for some reason, and the 25th patch was missing the new files, paravirt.{c,h}. (although I do remember having git-add'ed it, but who knows...) Andrew, could you please push it

c/s 25336:edd7c7ad1ad2 introduced the concept of a bogus vector, for in irqs delivered through the i8259 PIC after IO-APICs had been set up. However, if supurious PIC vectors are received, many "No irq handler for vector" log messages can be seen on the console. This patch adds to the bogus vector logic to detect spurious PIC vectors and simply ignore them. _mask_and_ack_8259A_irq()

I attempted an upgrade of our production system from Asterisk/Zaptel 1.2 to 1.4 this weekend. Intially everything looked like it was working properly, but some time in the day following the upgrade, the system died to a kernel panic. I wasn't able to catch the entire kernel dump on the console unfortunately. I attempted to isolate the panic, and found that when 'service zaptel stop'

plain text document attachment (xx-paravirt-irqs.patch) Interrupt updates for paravirt ops. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/ia32/ia32entry.S =================================================================== --- clean-start.orig/arch/x86_64/ia32/ia32entry.S +++

plain text document attachment (xx-paravirt-irqs.patch) Interrupt updates for paravirt ops. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/ia32/ia32entry.S =================================================================== --- clean-start.orig/arch/x86_64/ia32/ia32entry.S +++

I hope this EIP can enlightend the developers: Jun 10 10:28:59 shawarma kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000019 Jun 10 10:28:59 shawarma kernel: printing eip: Jun 10 10:28:59 shawarma kernel: c0181d47 Jun 10 10:28:59 shawarma kernel: *pde = 00000000 Jun 10 10:28:59 shawarma kernel: Oops: 0000 [#1] Jun 10 10:28:59 shawarma kernel: Modules linked in:

Usage: vga="qxl" Reposted for xen 4.4, require SSE support on hvm domU otherwise it works only as a standard vga. Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz> Signed-off-by: Zhou Peng <zpengxen@gmail.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> --- docs/man/xl.cfg.pod.5 |

Hi all, my name is Hirofumi Tsujimura. We are porting and testing a PV-on-HVM in the IPF. This is a first time to send mail. I probably found the problem when I tested the VNIF. My operation for the test is following. 1. create a domain VTx and attach the VNIF in it. 2. create a domain U. 3. send a packet to the domain VTx from the domain U with ping command. Then, the domain VTx

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

When I came into work this morning the console had the following: bio_endio __end_that_request_first scsi_end_request scsi_io_completion scsi_finish_command scsi_softirq __do_softirq do_softirg do_irq command_interrupt default_idle cpu_idle start_kernel Panic I am running software RAID-1 on this machine. I had 2 IDE disks and the machine when down once in a while with similiar messages. I