much more latency sensitive to memory than most PCI devices.
It's not surprising chipset designers make this tradeoff.
> > Does anyone know what the achievable DMA latency should be, and what I
> > can tune on the zx1 chipset or PCI card?
1000ns is a bit high but expect ~800ns or
On Wed, Oct 10, 2007 at 11:08:31AM +0200, Andreas Schwab wrote:
> Grant Grundler <[EMAIL PROTECTED]> writes:
>
> > 2) But I'm getting this error:
> > CC [M] drivers/char/ipmi/ipmi_si_intf.o
> > drivers/char/ipmi/ipmi_si_intf.c:1095: error: __param_hotmod
Hi folks,
After a long break, I'm trying to update the kernel on my ia64 HP zx2000.
Config file is attached. Two issues with kernel.org 2.6.23:
1) Can't build with NUMA=n and DISCONTIG=y.
Build quickly dies with NODE_DATA being undefined.
I tried to "work around" it with two changes:
a) i
Hi,
Helge Deller recently posted a Linux Test Project test failure
on the parisc-linux mailing list:
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-December/031030.html
I took the code snippet he posted and tried to compile/run that
on x86 (no problems) and ia64 (undefined reference to
On Wed, Sep 07, 2005 at 04:52:17PM +0800, Coywolf Qi Hunt wrote:
> On 9/7/05, Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> > Repost previously discussed patch (on Jul 27, 2005).
For reference:
http://www.gelato.unsw.edu.au/archives/linux-ia64/0507/14686.html
> Do you have any benchmarks?
Have yo
On Fri, Sep 02, 2005 at 11:16:10AM -0700, david mosberger wrote:
> > Sorry - I think this is BS.
> >
> > Please run mmio_test on your box and share the results.
> > mmio_test is available here:
> > svn co http://svn.gnumonks.org/trunk/mmio_test/
>
> Reads are slow, sure, but writes are no
On Thu, Sep 01, 2005 at 05:45:54PM -0500, Brent Casavant wrote:
...
> The first is serialization of all I/O reads and writes. This will
> be a severe problem on systems with large numbers of PCI buses, the
> very type of system that stands the most to gain in reliability from
> these efforts. At
On Wed, Aug 24, 2005 at 09:54:41AM +0530, Santosh Abraham wrote:
> Any good reading available on why we need
> a hugetlbfs ?
Yes. Googling got me here:
http://developer.osdl.org/maryedie/LWE_NYC04_Links.html
See the top couple of links.
You might also read about superpages to get some o
On Wed, Jul 06, 2005 at 02:11:42PM +0900, Hidetoshi Seto wrote:
> [This is 5 of 10 patches, "iochk-05-check_bridge.patch"]
...
> It means that A or B hits a bus error, but there is no data
> which one actually hits the error. So, C should notify the
> error to both of A and B, and clear the H
On Fri, Apr 08, 2005 at 09:05:48PM -0700, David Mosberger wrote:
...
> #if __GNUC__ >= 4 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
> # define popcount(x) __builtin_popcountl(x)
> #else
> # define popcount(x) ia64_popcnt(x)
> #endif
Ah - thanks!
I didn't know how gcc versions could
On Fri, Apr 08, 2005 at 04:49:11PM -0700, David Mosberger wrote:
> With the attached test-program, I'm seeing these results on a 1.5GHz
> Madison:
I've committed test_fls.c to CVS at:
http://cvs.parisc-linux.org/build-tools/
It requires at least gcc-3.4 for ia64.
gcc-3.3 will fail with:
On Fri, Apr 08, 2005 at 04:15:43PM -0700, Matt Mackall wrote:
> > static inline int
> > fls (int x)
> > {
> > if (!x)
> > return 0;
> > return ia64_fls((unsigned int) x) + 1;
> > }
>
> I was trying desperately to avoid the branch, as I understand there
> are issues there on IA6
On Tue, Apr 05, 2005 at 10:15:18PM -0700, Gerrit Huizenga wrote:
> SpecSDET, Aim7 or ReAim from OSDL are probably what you are thinking of.
SDET isn't publicly available.
I hope by now osdl-reaim is called "osdl-aim7":
http://lkml.org/lkml/2003/8/1/172
grant
-
To unsubscribe from this lis
On Wed, Mar 09, 2005 at 12:12:37PM -0600, Colin Ngam wrote:
> The MSI address portion allows 64bits for the address.
Yes - *allows*. It also allows devices to implement 32-bit MSI address.
MSI "Control" bits indicate what is implemented.
See PCI2.2 spec or later and search for MSI.
> I am very mu
On Wed, Mar 09, 2005 at 11:42:39AM -0600, Colin Ngam wrote:
> >We'll have to figure out which platform specific hooks would enable
> >parisc/alpha/altix to use existing PCI MSI/MSI-X support.
>
> Sounds great.
Indeed. :^)
I forgot to mention I've had this on my wish list for ~5 years...
http://li
On Tue, Mar 08, 2005 at 10:09:58PM -0700, dann frazier wrote:
> Is this the right way to approach a patch to fix this?
It looks right. But I'd expect arch/ia64/mm/discontig.c to use whats
in the header file so everyone is using the same definition.
> +#ifdef CONFIG_SMP
> void *per_cpu_init(void)
On Wed, Mar 09, 2005 at 08:35:00AM -0800, Nguyen, Tom L wrote:
> Existing MSI support implements a direct
> memory-write mechanism (generic solution without platform dependency and
> limitation to MSI-X support as an example). With existing direct
> memory-write mechanism, a device's MSI address is
On Tue, Mar 08, 2005 at 05:29:13PM -0800, Jesse Barnes wrote:
...
> An MSI should behave like a processor sending an IPI to itself since its
> address can be targeted at the processor's interrupt block and set to
> generate a local interrupt. Is that right, Tom & Grant?
Yes - that's how I under
On Mon, Mar 07, 2005 at 02:40:42PM -0600, Colin Ngam wrote:
> I looked at Documentation/MSI-HOWTO.txt(linux-ia64-release-2.6.11) and
> it mentioned that CONFIG_X86_LOCAL_APIC has to be configured. I did not
> find this configured on in any sample ia64 config files, but it does
> exist in defcon
On Mon, Mar 07, 2005 at 03:40:56PM -0800, Jesse Barnes wrote:
> Cool, I was hoping it just pointed at the same place we use for IPIs. It
> *should* work on Altix then, assuming the MSI allocation routines don't have
> platform knowledge in them (like ACPI bits or something).
I submitted a patch
On Mon, Mar 07, 2005 at 03:11:46PM -0800, Jesse Barnes wrote:
> So the MSIs are programmed to point at the processor SAPIC block? I think
> that'll work for us on Altix, but if they're pointed at an external Intel (or
> compatible) interrupt controller, we'll have to write new code for Altix.
A
On Fri, Mar 04, 2005 at 05:42:08PM -0600, Colin Ngam wrote:
> Is MSI/MSIX support available for ia64?
Yes
> Are PCIE devices supported in ia64?
I'm having trouble with the word "supported".
You have a PCI-E Bridge and firmware that can talk to it
hooked up to an ia64 box?
Anyway, linux has some
On Mon, Feb 28, 2005 at 06:06:00PM +, Matthew Wilcox wrote:
>
> Not sure where the problem lies on this one ...
>
> On an hp rx4640, at shutdown of an unmodified 2.6.11-rc5 kernel, I get:
>
> Rebooting... ACPI: PCI interrupt for device :a1:04.0 disabled
> iosapic_unregister_intr(42949672
On Tue, Feb 15, 2005 at 03:43:10AM -0500, Jes Sorensen wrote:
> None of the ones I know well have this problem, but I have little
> knowledge about this level of stuff on most architectures. The ones
> that could have issues would probably be like PPC, PARISC and maybe
> Alpha .
With parisc 2.
On Tue, Feb 08, 2005 at 03:45:25PM -0800, Luck, Tony wrote:
> 2) I saw one user process failure ... while stressing the system with a
> "make -j16" kernel build, one of the complilations error'd out with a
> bizarre internal gcc error. So possibly a register was corrupted???
Likely yes.
That's on
On Thu, Jan 20, 2005 at 08:43:30AM +1100, Paul Mackerras wrote:
> I suggest read_poll(), write_poll(), spin_poll(),...
Erm...those names sound way too much like existing interfaces.
Perhaps check_read_lock()/check_write_lock() ?
If they don't get used too much, the longer name should be ok.
gran
26 matches
Mail list logo
