An error occurred fetching the project authors.
- 03 Apr, 2003 5 commits
-
-
David Mosberger authored
-
Alex Williamson authored
This removes platform_pci_dma_address. Since the scatterlist in 2.5 has a dma_address, seems like we can expect a certain usage of it. SGI folks may want to verify this doesn't break their DMA engines.
-
Alex Williamson authored
trivial build fix for the generic kernel target
-
David Mosberger authored
Fix spelling of Hewlett-Packard.
-
Xavier Bru authored
3) with CONFIG_NUMA set, there are undefined symbols building modules: scripts/modpost vmlinux drivers/md/dm-mod.o drivers/net/e1000/e1000.o drivers/net/eepro100.o drivers/md/md.o drivers/net/mii.o fs/xfs/xfs.o *** Warning: cpu_info__per_cpu [fs/xfs/xfs.ko] undefined! *** Warning: cpu_info__per_cpu [drivers/md/md.ko] undefined! *** Warning: cpu_to_node_map [drivers/md/md.ko] undefined! exporting them in ia64_ksyms.c fixes the problem.
-
- 31 Mar, 2003 3 commits
-
-
David Mosberger authored
-
Martin Hicks authored
Consolidate the uses of cpu_is_online() to use the (relatively) new cpu_online() macro.
-
Jesse Barnes authored
We need readX() to be machine vectors since some platforms don't provide DMA coherence via PIO reads (PCI drivers and the spec imply that this is a good idea). Writes are ok though for all existing ia64 platforms (and hopefully it'll stay that way).
-
- 27 Mar, 2003 6 commits
-
-
David Mosberger authored
ia64 compilers, not just GCC.
-
David Mosberger authored
-
Andreas Schwab authored
When an ia32 process triggers request_module the kernel cannot execute modprobe because the kernel thread still has the ia32 address limits in force. I think a kernel thread should always have the ia64 address limits, similar to what sys32_execve is doing.
-
Jes Sorensen authored
A small patch for 2.4 that stops the kernel from trying to syncrhonize ITC clocks between CPUs if we know that the ITC isn't synchronized across the backplane.
-
Kochi Takayoshi authored
My e-mail address changed and I'd like to update it in arch/ia64/kernel/acpi.c.
-
David Mosberger authored
-
- 26 Mar, 2003 8 commits
-
-
Andreas Schwab authored
I've found this by inspecting the code: pt_regs_off returns an offset into struct pt_regs. Relative to latest bk, 2.5 has the same bug.
-
Eric Piel authored
Eric Piel wrote: > However, now, it still gives negative difference: > # ./a.out > requested: 1047572128s 2564ns > new: 1047572128s 1588ns > diff is -0.000976000sec > > That's better but there is still something... > Can anyone reproduce this bug? Any idea about what may cause this > shifted results? > > I don't understand what does the line in settimeofday(): > nsec -= (jiffies - wall_jiffies ) * (1000000000 / HZ); Finally I read the code to do the same thing for i386 (get and settimeofday()). This explains the meaning of this line, in the i386 it's associated with the equivalent line in do_gettimeofday()! On ia64 everything is done inside of gettimeoffset(). Therefore I'm now confident that suppressing this line is a Good Thing ;-) The patch doing it wrt the bk tree is attached. The test case confirms that it works: requested: 1048681051s 194873ns new: 1048681051s 194874ns diff is 0.000001000sec That's the same result than on a 2.4.19 . This also solved an error on the high resolution timers test suite.
-
David Mosberger authored
-
David Mosberger authored
-
David Mosberger authored
-
David Mosberger authored
-
David Mosberger authored
-
David Mosberger authored
-
- 25 Mar, 2003 1 commit
-
-
David Mosberger authored
the handling of loader-created sections.
-
- 24 Mar, 2003 3 commits
-
-
Wolfgang Mauerer authored
the attached patch (against bk-current) fixes a cross compilation problem by using the target specific objdump tool instead of the host specific one.
-
David Mosberger authored
ia64_sal_mc_rendez(). Also prefix local-variables in SAL macros to avoid name collisions.
-
Keith Owens authored
We are not setting the 'always rendezvous for mca' flag. kdb needs it set to get decent mca debugging on all cpus but I do not want kdb to change sal behaviour. Since we do not recover from mca without a debugger, I see no reason why this flag should not be on for all kernels. The rendezvous timeout was set to 100 * HZ, but SAL expects the timeout to be in milliseconds, HZ may not be 1 millisecond. The patch makes the timeout an explicit 20 seconds, semi-arbitrary value.
-
- 21 Mar, 2003 3 commits
-
-
David Mosberger authored
thoroughly broken ia64 patch). Not all relocs are supported yet and the reloc code needs to be cleaned up, but simply stuff like loading the palinfo module works. Also, linkage-stubs are optimized with brl for McKinley or better.
-
David Mosberger authored
-
Vladimir Simonov authored
Trying to port some patches from i386 to ia64 I've found that show_trace_task is the only portable way to show tasks' call traces(perhaps because it is called from ./kernel/sched.c:)). But its ia64 implementation can't work with running task. Attached patch fixes this issue. As I understand show_trace and show_stack are platform dependent or have different sense/args.
-
- 19 Mar, 2003 1 commit
-
-
Alex Williamson authored
Here's patches for 2.4 & 2.5 to use PAL_HALT_LIGHT in cpu_idle. This helps to reduce CPU temp a little on boxes with firmware that takes advantage of this lower power state. I've tried this on a rx2600 (2x900MHz McKinley) and an i2000 (fw 117) and it shows some benefit. On McKinley systems, only the very latest PAL from Intel actually reduces power consumption in the halt_light state. For HP rx2600/zx6000/zx2000, this means you need to be running firmware 1.82. Rohit Seth, at Intel, has run some benchmarks with this kind of modification and found the effects of enabling halt_light to fall within the noise of mosts tests. I replaced pal_halt(1) in safe_halt with pal_halt_light() since halt_light is required to be implemented, but pal_halt(1) is an optional halt state. I'd be interested to hear of any measurements anyone does using this, where it works/fails, and if any benchmarks/applications are impacted.
-
- 18 Mar, 2003 4 commits
-
-
Jesse Barnes authored
David, here's an updated patch that doesn't mess with arch/ia64/Makefile in case you hadn't applied the last one yet
-
Martin Hicks authored
Here is a simple patch to also print isr during the handling of a floating point assist fault.
-
Jesse Barnes authored
The consensus on lkml was that devices should do reads from safe registers to ensure PIO write ordering, which means we no longer need mmiob. This patch removes the mmiob entries from the machine vector headers and io.h and updates the documentation about PIO ordering.
-
David Mosberger authored
should not use such innocent variable names like tmp because they have a high probability to clash with (part of) the argument.
-
- 14 Mar, 2003 2 commits
-
-
Keith Owens authored
The patch allows unw_access_gr() to read from r0, to support unwind directives such as .save ar.pfs,r0 and .save rp,r0.
-
David Mosberger authored
-
- 13 Mar, 2003 3 commits
-
-
Eric Piel authored
Here is a patch to have the POSIX timer interface completly integrated in ia64 (2.5.64). The programs in userland can now access the siginfo structure. With that patch the test programs of the high resolution timers pass without error but one which seems to also be triggered on ix86: nanosleeps too short.
-
David Mosberger authored
-
Jakub Jelínek authored
do_fork is declared as: struct task_struct *do_fork(unsigned long clone_flags, unsigned long stack_start, struct pt_regs *regs, unsigned long stack_size, int *parent_tidptr, int *child_tidptr) ie. parent_tidptr is out4 and child_tidptr is out5, but the comments in clone2 were suggesting otherwise. So, we either need a patch which will codify current order of clone arguments (ie. ptid, ctid, tls; attached below - has the advantage that clone2 stays with the same ABI as in 2.5.[56]x), or the arguments of clone2 and clone should be reordered to match the IA-32 order (which is ptid, tls, ctid).
-
- 11 Mar, 2003 1 commit
-
-
David Mosberger authored
-