fa.linux.kernel Google Group

[patch 3/8] x86: UV - Introduce uv_gpa_is_mmr.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:41:36 UT

Provide a mechanism for determining if a global physical address is
pointing to a UV hub MMR.
To: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Robin Holt <h...@sgi.com>
Cc: Jack Steiner <stei...@sgi.com>
Cc: lkml <linux-ker...@vger.kernel.org>
Cc: linux...@vger.kernel.org
---
arch/x86/include/asm/uv/uv_hub .h | 7 +++++++

[patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:41:32 UT

Under heavy load conditions, our set of xpc messages may become exhausted.
The code handles this correctly with the exception of the management
code which hits a NULL pointer dereference.
To: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Robin Holt <h...@sgi.com>
Cc: Jack Steiner <stei...@sgi.com>

[patch 8/8] [patch 8/8] X86: UV - XPC receive message reuse triggers invalid BUG_ON().

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:41:11 UT

This was a difficult bug to trip. XPC was in the middle of sending an
acknowledgement for a received message.
In xpc_received_payload_uv():
.
ret = xpc_send_gru_msg(ch->sn.uv.cac hed_notify_gru_mq_desc, msg,
sizeof(struct xpc_notify_mq_msghdr_uv));
if (ret != xpSuccess)

[patch 7/8] X86: UV - xpc_make_first_contact hang due to not accepting ACTIVE state.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:41:04 UT

Many times while the initial connection is being made, the
contacted partition will send back both the ACTIVATING and the ACTIVE
remote_act_state changes in very close succescion. The 1/4 second delay
in the make first contact loop is large enough to nearly always miss
the ACTIVATING state change.
Since either state indicates the remote partition has acknowledged our

[patch 2/8] x86: UV - XPC needs to provide an abstraction for uv_gpa.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:40:55 UT

Provide an SGI SN2/UV agnositic method for converting a global physical
address into a socket physical address.
To: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Robin Holt <h...@sgi.com>
Cc: Jack Steiner <stei...@sgi.com>
Cc: lkml <linux-ker...@vger.kernel.org>
Cc: linux...@vger.kernel.org

[patch 5/8] x86: UV - Update XPC to handle updated BIOS interface.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:40:39 UT

The UV BIOS has moved the location of some of their pointers to the
"partition reserved page" from memory into a uv hub MMR. The GRU does
not support bcopy operations from MMR space so we need to special case
the MMR addresses using VLOAD operations.
Additionally, the BIOS call for registering a message queue watchlist

[patch 4/8] X86: UV - Implement a gru_read_gpa kernel function.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:40:24 UT

The BIOS has decided to store a pointer to the partition reserved page
in a scratch MMR. The GRU is only able to read an MMR using a vload
instruction. The gru_read_gpa() function will implemented.
To: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Robin Holt <h...@sgi.com>
Signed-off-by: Jack Steiner <stei...@sgi.com>

[patch 0/8] x86: UV - XPC fixes with related support functionality V2.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:40:03 UT

The UV BIOS has been updated to implement some of our interface
functionality differently than originally expected. These patches update
the kernel to the bios implementation and include a few minor bug fixes
which prevent us from doing significant testing on real hardware.
Changes from V1:
- Actually include the patch introducing the gru_read_gpa. This

[patch 1/8] x86: UV - Introduce a means to translate from gpa -> socket_paddr.

h...@sgi.com (Robin Holt) — Tue, 24 Nov 2009 01:40:11 UT

For SGI UV systems, translate from a global physical address back to
a socket physical address. This does nothing to ensure the socket
physical address is actually addressable by the kernel. That is the
responsibility of the user of the function.
To: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Robin Holt <h...@sgi.com>

[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame

wcan...@gmail.com (Ang Way Chuang) — Tue, 24 Nov 2009 01:34:17 UT

ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.32-rc8. Similar patch

Re: Vortex86SX: only works with irqpoll

hancock...@gmail.com (Robert Hancock) — Tue, 24 Nov 2009 01:29:40 UT

Looking at the BIOS manual on their web site:
[link]
you can try toggling a few of the options: Try switching OnBoard IDE
Operate Mode between Legacy Mode and Native Mode. If the kernel and the
actual device disagree here, that could cause IRQ delivery problems. You

Re: [PATCH 2/2] perf kmem: resolve symbols

a...@infradead.org (Arnaldo Carvalho de Melo) — Tue, 24 Nov 2009 01:20:54 UT

Em Tue, Nov 24, 2009 at 08:50:57AM +0800, Li Zefan escreveu:
Ok, I'll have some sleep now, hack away! :-)
- Arnaldo

Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5)

ja...@shareable.org (Jamie Lokier) — Tue, 24 Nov 2009 01:20:48 UT

I think we can mostly agree on that :-)
Anything which compiled with and uses the openat(), mkdirat()
etc. emulation in gnulib (formerly known as libiberty), and anything
using the same technique.
You know, GNU coreutils and other obscure things :-)
Of course there are real system calls for that, now, but there are

Re: linux-next: manual merge of the mips tree with the net-current tree

r...@linux-mips.org (Ralf Baechle) — Tue, 24 Nov 2009 01:20:09 UT

I agree. David, can you just drop the net-current patch then? This fix
is still needed for -stable however.
Ralf

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

awa...@radix.net (Andy Walls) — Tue, 24 Nov 2009 01:16:03 UT

The underlying hardware need not be completely independent.
For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
chips have IR hardware that shares a common timing source, interrupt
line, interrupt status register, etc, between IR Rx and Tx. They can
also do things like loopback of Tx to Rx.