Revision 42b5212fee4f57907e9415b18fe19c13e65574bc authored by David Vrabel on 02 February 2015, 16:57:51 UTC, committed by David S. Miller on 03 February 2015, 03:39:04 UTC
After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
disable rogue vif in kthread context), a fatal (protocol) error would
leave the guest Rx thread spinning, wasting CPU time.  Commit
ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
guest Rx stall detection) made this even worse by removing a
cond_resched() from this path.

Since a fatal error is non-recoverable, just allow the guest Rx thread
to exit.  This requires taking additional refs to the task so the
thread exiting early is handled safely.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reported-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 parent 5a2e87b
Raw File
debugging
okay, here are some hints for debugging the lower-level parts of
linux/parisc.


1. Absolute addresses

A lot of the assembly code currently runs in real mode, which means
absolute addresses are used instead of virtual addresses as in the
rest of the kernel.  To translate an absolute address to a virtual
address you can lookup in System.map, add __PAGE_OFFSET (0x10000000
currently).


2. HPMCs

When real-mode code tries to access non-existent memory, you'll get
an HPMC instead of a kernel oops.  To debug an HPMC, try to find
the System Responder/Requestor addresses.  The System Requestor
address should match (one of the) processor HPAs (high addresses in
the I/O range); the System Responder address is the address real-mode
code tried to access.

Typical values for the System Responder address are addresses larger
than __PAGE_OFFSET (0x10000000) which mean a virtual address didn't
get translated to a physical address before real-mode code tried to
access it.


3. Q bit fun

Certain, very critical code has to clear the Q bit in the PSW.  What
happens when the Q bit is cleared is the CPU does not update the
registers interruption handlers read to find out where the machine
was interrupted - so if you get an interruption between the instruction
that clears the Q bit and the RFI that sets it again you don't know
where exactly it happened.  If you're lucky the IAOQ will point to the
instruction that cleared the Q bit, if you're not it points anywhere
at all.  Usually Q bit problems will show themselves in unexplainable
system hangs or running off the end of physical memory.
back to top