On Thu, Jan 11, 2001 at 12:59:24AM +0100, Andrea Arcangeli wrote:
What I said is that I can write this C code:
int x[2], * p = (int *) (((char *) x)+1);
main()
{
*p = 0;
}
This is legal C code.
Err, no. This is not "legal" by any stretch of the
On Wed, Jan 24, 2001 at 10:02:40AM +0100, Andrea Arcangeli wrote:
I'd love if you could forbid it to compile.
Problem is that there's stuff like this all over the place. Plus,
just because something is undefined by the standard doesn't mean
it's not useful -- it's not possible to write either
On Wed, Jan 24, 2001 at 01:21:44PM +0100, Andrea Arcangeli wrote:
For example you don't know if there's another object that will cast
the int pointer back to char pointer before dereferencing. That would
get a defined runtime behaviour on all archs.
No. The representation of "int*" and
On Fri, May 18, 2001 at 09:46:17PM +0400, Ivan Kokshaysky wrote:
-void
-cia_pci_tbi(struct pci_controller *hose, dma_addr_t start, dma_addr_t end)
-{
- wmb();
- *(vip)CIA_IOC_PCI_TBIA = 3; /* Flush all locked and unlocked. */
- mb();
- *(vip)CIA_IOC_PCI_TBIA;
-}
I'd
On Sun, May 20, 2001 at 04:05:18PM +0400, Ivan Kokshaysky wrote:
Ok. What do you think about reorg like this:
basically leave the old code as is, and add
if (is_pyxis)
alpha_mv.mv_pci_tbi = cia_pci_tbi_try2;
else
tbia test
...
On Mon, May 21, 2001 at 12:19:49AM +0200, Ingo Oeser wrote:
AFAIK const is only a promise to the compiler, that we write
this data ONCE and read only after this initial write. So the
decision on the section is implementation defined.
No, the problem is not with which section, but what flags
On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
does cause a section conflict, egcs 1.1.2.
Interestingly enough, if var[12] are together, without the intervening
text, then gcc does not flag an error, instead it puts both variables
in section .data.init and marks it as read
On Sun, May 20, 2001 at 06:03:44PM -0700, David S. Miller wrote:
But for the time being, everyone assumes address zero is not valid and
it shouldn't be too painful to reserve the first page of DMA space
until we fix this issue.
Indeed, virtually all PCI systems have legacy PeeCee
On Mon, May 21, 2001 at 03:51:51PM +0400, Ivan Kokshaysky wrote:
I'm unable reproduce it with *8Mb* window, so I'm asking.
Me either. But Tom Vier, the guy who started this thread
was able to use up the 8MB. Which is completely believable.
The following should aleviate the situation on these
On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote:
64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't
apply to bus-master DMA, just the legacy (8237) stuff.
Would this 8237 be something on the ISA card, or something on
the old pc mainboards? I'm wondering if we can
On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote:
I'm also wondering if ISA needs the sg to start on a 64k boundary,
Traditionally, ISA could not do DMA across a 64k boundary.
The only ISA card I have (a soundblaster compatible) appears
to work without caring for this, but I
On Tue, May 22, 2001 at 04:40:17PM -0400, Jeff Garzik wrote:
ISA cards can do sg?
No, but the host iommu can. The isa card sees whatever
view of memory presented to it by the iommu.
r~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
PALcode will ack the interrupt in the normal interrupt return path,
but 2.4 re-enables interrupts before that. This means we re-enable
interrupts without the hardware being acked, which results in nasty
interrupt storms.
Fixed thus.
r~
--- linux/arch/alpha/kernel/sys_rawhide.c.orig Sun May
On Sun, May 27, 2001 at 07:54:17PM -0400, Jeff Garzik wrote:
FWIW the documentation seems to imply that the option is necessary only
when directly booting from SRM, i.e.. no bootloader is involved at all.
Err, well, you can't have _no_ bootloader.
It uses the example of MILO's presence or
On Sat, May 26, 2001 at 06:48:30PM -0400, Jeff Garzik wrote:
When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails.
Mine doesn't.
I am booting w/ aboot 0.7a from SRM, -without- the
srm-as-bootloader kernel config option.
That is the error.
r~
-
To unsubscribe from this
On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote:
Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version
2.96-ia64-000717 snap 000828. It complained about various include
files, "pasting would not give a valid preprocessing token", this
version of gcc is a bit more
On Tue, Aug 29, 2000 at 04:26:18AM +0200, Andrea Arcangeli wrote:
Just to make a fun example if the virtual address of ld_l/st_c are
different but within the same 16bytes natuarlly aligned block you have to
put an mb() in __between__ ld_l/st_c to make sure that they are not
reordered and that
On Fri, Sep 01, 2000 at 12:09:23AM -0700, Linda Walsh wrote:
Perhaps an "easy" way to go would be to convert block numbers to
type "block_nr_t", then one could measure the difference that 10's of
nanoseconds make against seeks and reads of disk data.
That's not the issue. The issue is
On Thu, Sep 07, 2000 at 09:51:26PM +0400, [EMAIL PROTECTED] wrote:
dummy_lock trick is equivalent to "memory" clobber.
No it's not. We know how big the dummy_lock structure is, and
so might "know" that it doesn't overlap with something else.
r~
-
To unsubscribe from this list: send the line
On Fri, Sep 08, 2000 at 12:34:24AM +0200, Andrea Arcangeli wrote:
No it's not. We know how big the dummy_lock structure is, and
so might "know" that it doesn't overlap with something else.
I guess Alexey point is that the current compiler doesn't notice that.
Perhaps. But that's not to
On Fri, Sep 08, 2000 at 08:36:58PM +0400, Ivan Kokshaysky wrote:
FWIW, here are __xchg_u8 and __xchg_u16 for Alpha.
I like it.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
There are two main purposes to this reorg:
* Split up the tremndously huge xor.c.
* Make it easier to write pure assembly routines without having
to interface with C structure offsets. You can see how nasty
the Alpha and Sparc64 routines were; it promised to be even
worse for
On Mon, Sep 11, 2000 at 08:48:24AM -0700, Linus Torvalds wrote:
- Please split this up the same way the checksums were split up:
make the xor routine be an architecture-dependent library thing, with
the "generic" slow one possibly just a regular library thing.
This is simple enough to
On Wed, Sep 13, 2000 at 12:26:39AM +0100, Russell King wrote:
If its 15K, and you're compiling raid as modules, why can't this code
also be compiled as a module in the architecture tree? Last time I
looked, modprobe handled dependencies between modules.
With the code as-is, you'd have half
On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
IMHO it's a bug in gcc that it does not inline the comparison inside the
switch expression, since it already does it in all other places. Perhaps
some problem with the patterns in the machine description.
Perhaps, but without a
On Tue, Sep 19, 2000 at 09:52:15AM -0700, Richard Henderson wrote:
Instead of *= 0.5, try /= 2.0
Yes indeed you've found a bug in the kernel's FP emulation.
I'll see about fixing it.
Rather than fix the old udiv128 function, which was trying to do
128/128 bit division, I've pulled
On Fri, Sep 22, 2000 at 04:10:18PM -0600, Michal Jaegermann wrote:
PCI: Failed to allocate resource 1 for Symbios Logic Inc. (formerly
NCR) 53c875
...
This is a PCI layout as reported by 'lspci -tv':
-[00]-+-0d.0-[01]--+-0a.0 Trident Microsystems 4DWave DX
|\-0d.0
On Mon, Sep 25, 2000 at 04:22:38AM -0500, Jeff Garzik wrote:
To give us a knowledge jump start... what is broken?
As far as I can tell, everything wrt actually configuring bridges.
If a bridge is completely uninitialized, then it won't be properly
added to the bus heirarchy, and neither will
On Sat, Sep 30, 2000 at 09:36:56PM +0200, Marc Lehmann wrote:
Various people I associate with being senior in both glibc and gcc (people
like Ulrich Drepper and Jeff Law) were involved in the compiler and glibc
they were involved, but I have reason to doubt that they actually agreed.
You
On Wed, Oct 04, 2000 at 12:30:12AM -0600, Michal Jaegermann wrote:
trident: DMA buffer beyond 1 GB; bus address = 0x48158000, size = 32768
You're screwed with 2.2. The poor trident only has 30 address
lines connected. You might try with 2.4, since there we attempt
to make use of the iommu to
On Tue, Sep 19, 2000 at 08:58:06PM -0700, David S. Miller wrote:
Is this a serious patch submission or just a call for testing? If the
former, I need to cook up the sparc bits once it gets in :-)
Huh? A serious patch submission, since it fixes a bug.
Why would you need to cook up any sparc
On Tue, Sep 19, 2000 at 04:32:16PM +0200, Andrea Arcangeli wrote:
Wrong: it's really loading the _address_.
[...]
80483f5: a1 a4 95 04 08 mov0x80495a4,%eax
^^^ ^
No, that's an absolute memory load. If we were loading
the
On Wed, Oct 04, 2000 at 05:25:44PM -0700, David S. Miller wrote:
These items are specifically placed into the data section, not the
BSS, because these alignment games are not possible in the BSS.
Compile with -fno-common and you'll get .bss, but not COMMON,
variables. It's the COMMON bits
On Thu, Oct 05, 2000 at 09:59:08PM -0700, David S. Miller wrote:
Compile with -fno-common and you'll get .bss, but not COMMON,
variables. It's the COMMON bits that are screwing your games.
Oh, I was just thinking too -- have you given any thought
to what happens on .sdata hosts even
On Sat, Oct 07, 2000 at 06:38:00PM +0100, Dave Gilbert wrote:
It looses interrupts in the IDE probes; it is a CMD646 controller and
what appears to be happening is that it is getting the wrong IRQs...
This was a generic ide problem in test9.
r~
-
To unsubscribe from this list: send the
On Fri, Oct 13, 2000 at 08:15:46PM +0400, Ivan Kokshaysky wrote:
On Thu, Oct 12, 2000 at 01:18:53PM -0700, Linus Torvalds wrote:
See the arch/x86/mm/fault.c changes to see what arch-specific changes this
can entail.
This patch works for me...
You shouldn't have needed any changes at all
On Fri, Oct 13, 2000 at 02:23:44PM -0700, Linus Torvalds wrote:
... but on a 3-level page table (whether with PAE on x86 or on alpha),
you could easily just decide to limit the vmalloc() area to a a gigabyte
or two and handle it with just one PGD entry..
I'm undecided. For normal usage,
On Tue, Oct 17, 2000 at 10:40:12AM +0100, Bernd Schmidt wrote:
I compiled using "gcc -S -Wall -O2 -fomit-frame-pointer -m486" to generate
the assembler code. The old code is 17 instructions long and the new code
is 11 instructions. As well as being shorter, simple timing test indicate
On Tue, Nov 21, 2000 at 06:46:09PM +0300, Ivan Kokshaysky wrote:
Interesting, other pyxis machines do not seem to be so sensitive,
so I guess some design problems with ux164 motherboard - all this
looks pretty much like timing issues.
Wow. Thanks for following through on this.
r~
On Sat, Dec 09, 2000 at 09:43:00AM +0100, Abramo Bagnara wrote:
alpha-mb-2.4.diff add missing defines from core_t2.h for non generic
kernel (against 2.4.0test11)
These are not "missing". They are intentionally not present
so that stuff will be done out of line.
r~
-
To unsubscribe from this
On Sun, Dec 10, 2000 at 10:40:12AM +0100, Abramo Bagnara wrote:
And this would be the only core_*.h files where this intention is
expressed?
Not at all. See core_lca.h, jensen.h, core_cia.h, core_mcpcia.h.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sun, Dec 10, 2000 at 08:04:07PM +0100, Abramo Bagnara wrote:
... the only missing things from core_t2.h are some defines to
permit to it to work when CONFIG_ALPHA_T2 is defined.
Have you tried it? I did. It works fine.
What _is_ defined in asm/core_t2.h is enough for alpha/lib/io.c to
On Sun, Dec 10, 2000 at 10:23:20PM +0100, Abramo Bagnara wrote:
asm/io.h uses out of line function only when CONFIG_ALPHA_GENERIC is
defined, otherwise it uses (take writel as an example) __raw_writel that
IMHO need to be defined in core_t2.h.
Perhaps you should _show_ an actual failure
On Sat, Dec 30, 2000 at 05:18:25AM +0200, Matti Aarnio wrote:
As the patch by mr. Kokshaysky is quite different doing more work
(and not only label name changes), I would prefer Richard Henderson
to act as an umpire to tell if your patch is sufficient, or if that
big thing
On Tue, Jan 02, 2001 at 03:12:37PM -0500, Ghadi Shayban wrote:
{standard input}: Assembler messages:
{standard input}:139: Error: bad register name `%%mm0'
This is, in fact, a compiler bug. Somehow the "%%" in the
source didn't print as "%" as expected.
r~
-
To unsubscribe from this list:
On Sun, Jan 07, 2001 at 01:55:15PM +, Alan Cox wrote:
+ return -EPERM;
To stop a case where the fs gets corrupted otherwise. You can change that to
return 0 which is more correct but most not remove it.
While I suppose "0" is covered under "the result is
On Mon, Jan 08, 2001 at 06:16:25PM +0100, Andi Kleen wrote:
This patch just makes the SSE2 code conditional on ...
Pedanticly, this is SSE1 code.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Mon, Jan 08, 2001 at 08:50:01PM +0100, Erik Mouw wrote:
Is this really a kernel bug? This is common idiom in C, so gcc
shouldn't warn about it. If it does, it is a bug in gcc IMHO.
No, it is not a common idiom in C. It has _never_ been valid C.
GCC originally allowed it due to a mistake
On Sat, Oct 28, 2000 at 01:15:58PM +0200, Dominik Kubla wrote:
Even simpler: "gcc -V 2.7.2.3" or "gcc -V 2.95.2" or whatever...
Which was a nice idea, but it doesn't actually work. Changes
in spec file format between versions makes this fall over.
r~
-
To unsubscribe from this list: send the
On Mon, Oct 30, 2000 at 05:05:43AM -0600, Peter Samuelson wrote:
But I think it's since been fixed:
No.
Is there more subtle breakage?
Yes.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Sun, Oct 29, 2000 at 10:17:36AM -0500, Jerry Kelley wrote:
Can gcc generate ASM output with the source lines from the C file
interspersed as comments?
Not directly. However, gas will happily generate assembler listings
containing the C source. See "-alh".
r~
-
To unsubscribe from this
On Wed, Nov 01, 2000 at 09:46:19AM -0500, [EMAIL PROTECTED] wrote:
What versions of gcc produce the built-in functions?
2.95 and previous. In 2.96 somewhere we fixed a bug that
automatically prototypes these builtin functions for you;
ie with current code you get an undeclared function
On Thu, Nov 02, 2000 at 01:14:49PM +0100, Martin Dalecki wrote:
However what's the difference in respect of optimization between
unrolling the abs function by hand and relying on the built in?
Should be nothing. The expanded source expression should get
folded immediately to an ABS_EXPR node,
On Tue, Nov 07, 2000 at 10:09:34AM -0800, Reto Baettig wrote:
I have a problem whith Alpha SMP's which seems to be kernel-related. I
discussed this on the bug-glibc list but everybody seems to agree that
it cannot be a libc problem.
Indeed it does seem to be some sort of tlb flushing problem,
[ For l-k, the issue is that pci-pci bridges and the devices behind
them are not initialized properly. There are a number of Alphas
whose built-in scsi controlers are behind such a bridge preventing
these machines from booting at all. Ivan provided an initial
patch to solve this issue.
On Wed, Nov 08, 2000 at 10:56:23AM -0500, Jeff Garzik wrote:
Setting bit 1 in dev-resource[x].start, below, seems incorrect. Should
you be programming the PCI BAR directly, instead?
No, that's the reason this is a quirk. The hardware is already
only responding to one and only one address.
On Wed, Nov 08, 2000 at 02:25:13PM +0300, Ivan Kokshaysky wrote:
I relied on DEC^WIntel 21153 datasheet which says that to turn off
io/mem window this bridge must be programmed with base limit
values (and the code actually did that).
Interesting. I hadn't known that. It didn't actually
On Thu, Nov 09, 2000 at 01:03:36AM +0300, Ivan Kokshaysky wrote:
But actually I'm concerned that all this code doesn't work at all -
see reports from Michal Jaegermann (the bridge acts as if it drops
config space transactions randomly).
I have no idea what Michal is seeing. It does, however,
On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
FWIW, I just tested rth's update of your path on my x86 SMP box, and a
laptop with two CardBus bridges (two CardBus slots). Both worked
fine...
x86 doesn't use this code at all. Only alpha, arm, and mips.
r~
-
To unsubscribe
On Fri, Nov 10, 2000 at 05:33:34PM -0800, H. Peter Anvin wrote:
AFAIK, I think Linus tried this once, but ran into bugs in gcc.
We might very well try again in 2.5.
You'll definitely have to use a compiler later than gcc 2.95, since
there were in fact major bugs in this area. I'd be
On Sat, Nov 11, 2000 at 10:18:46PM -0500, Alexander Viro wrote:
Alternative variant: just let schedule() store its return address
in the task_struct.
Please please. I can't reliably unwind the stack on Alpha.
OTOH, the value is used only by Alt-SysRq-T, so... Hell knows.
No, it's also used
On Mon, Nov 13, 2000 at 12:51:24AM -0500, Jeff Garzik wrote:
Alas...
--- include/linux/init.h2000/10/30 19:37:38 1.1.1.5
+++ include/linux/init.h2000/11/13 04:30:02 1.1.1.6
@@ -73,7 +73,7 @@
-#define __init __attribute__ ((__section__ (".text.init")))
On Tue, Nov 14, 2000 at 09:58:00AM -0700, Michal Jaegermann wrote:
+#include asm/compiler.h
Ug. Of course, this is what I intended after having added
the define to compiler.h.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
- removed some mb's for non-SMP
This isn't correct. Either you need atomic updates or you don't.
If you don't, then you shouldn't be using ll/sc at all. If you do
(perhaps to coordinate with devices) then the barriers are
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
Initially I tried to use __builtin_expect in the rwsem.h, but found
that it doesn't help at all in the small inline functions - it works
as expected only in a reasonably large block of code.
Eh? Would you give me an example
On Sat, May 05, 2001 at 06:17:18PM +0400, Ivan Kokshaysky wrote:
Eh? Would you give me an example that isn't working properly?
Sure.
Fixed thus.
So one of the questions: can one rely on current branch predictions
algorithms (val 0, val = 0 false etc.) in the long term?
Err, no. We
We fixed a bug in cv-qualification checking.
timer.c:35: conflicting types for `xtime'
include/linux/sched.h:540: previous declaration of `xtime'
There's no need for the volatile qualification here. One, being a
struct it doesn't do any good, and two it's protected by xtime_lock.
r~
---
On Thu, Jun 14, 2001 at 07:21:22PM +0200, Andrea Arcangeli wrote:
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
[uses in glibc]
Yes, I saw those. What is the effect of O_NOFOLLOW? To not
follow symbolic links when opening the file. If you open a
regular
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
within glibc, and (2) making these accesses slower since they
will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which
On Fri, Jun 29, 2001 at 09:19:31PM +0400, Ivan Kokshaysky wrote:
Good idea. The patch below works reliably on my sx164.
Reasonable. Here I've cleaned up time_init a tad as well.
r~
--- arch/alpha/kernel/time.c.orig Fri Jun 29 11:24:03 2001
+++ arch/alpha/kernel/time.cFri Jun 29
On Thu, Feb 08, 2001 at 02:41:19PM +0300, Ivan Kokshaysky wrote:
- Don't trust IRQs assigned by ARC console on ruffian any more;
use interrupt routing table provided by [EMAIL PROTECTED] instead.
This fixes cards reporting bogus interrupt pin (ES1969).
Oh cool. I think this was the only
On Mon, Feb 12, 2001 at 02:33:17PM -0800, David S. Miller wrote:
You have to add a few bits to arch/alpha/kernel/traps.c
I could be wrong though...
Only to make the oops look pretty. Something like
die_if_kernel((type == 1 ? "Kernel Bug" : "Instruction fault"),
On Wed, Apr 11, 2007 at 12:30:48PM +0400, Ivan Kokshaysky wrote:
+VGA_MAP_MEM(unsigned long xaddr, unsigned int size)
+{
+ /* Create a new VGA ioport resource WRT the hose it is on. */
+ if (pci_vga_hose pci_vga_hose-index) {
+ static struct resource alpha_vga =
+
On Wed, Apr 11, 2007 at 12:28:41PM +0400, Ivan Kokshaysky wrote:
- __asm__(ctlz %1, %0 : =r(vector) : r(mask));
+ __asm__(.arch ev67; ctlz %1, %0 : =r(vector) : r(mask));
This should use __kernel_ctlz, and we should use
#ifdef __alpha_cix__
# if __GNUC__ == 3
On Thu, Apr 12, 2007 at 12:01:10PM +0400, Ivan Kokshaysky wrote:
[CIX stuff reworked, .got change dropped as Richard suggested]
Override compiler .arch directive for generic kernel build.
Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED]
Signed-off-by: Richard Henderson [EMAIL PROTECTED
On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=425794#c0
That bugzilla entry doesn't even have a dmesg output or anything like
that. I'd really like to see what the
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
On Tue, Dec 18, 2007 at 01:09:15PM -0800, Linus Torvalds wrote:
However, I wonder about that
e000-efff : pnp 00:0b
thing. I actually suspect that that whole allocation is literally *meant*
for that 256MB graphics aperture, but the kernel explicitly avoids it
because it's
On Tue, Dec 18, 2007 at 04:46:09PM -0500, Chuck Ebbert wrote:
pnpacpi=off should work.
This does result in the graphics bar being placed at e000,
and does result in a system lockup when X starts. So it appears
as if there's really something there.
r~
--
To unsubscribe from this list: send
On Tue, Dec 18, 2007 at 07:55:37PM -0500, Chuck Ebbert wrote:
You can boot with pci=mmconf to enable it.
Heh.
PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
PCI: Not using MMCONFIG.
r~
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Tue, Dec 18, 2007 at 05:38:58PM -0800, Linus Torvalds wrote:
That
PCI: Cannot allocate resource region 9 of bridge :00:01.0
PCI: Cannot allocate resource region 1 of device :01:00.0
thing is really starting to bug me.
I bet that is the real problem here, but it's
On Thu, Dec 20, 2007 at 02:24:48PM -0800, Linus Torvalds wrote:
I'm not exactly 100% happy with it, but it does mean that if we need a big
area, we'll relax the suggested starting point by that amount. It's not
wonderful, but it essentially admits that the minimum for the allocations
is
Recent build changes have added a PT_NOTE entry to the kernel's
ELF header. A perfectly valid change, but Alpha's aboot loader
is none too bright about examining these headers.
The following patch to aboot-1.0_pre20040408.tar.bz2 makes it
so that only PT_LOAD entries are considered for loading,
On Fri, Aug 03, 2007 at 10:09:16AM -0700, Ulrich Drepper wrote:
Alpha: probably needs value 01000
Thanks. Patch sent.
r~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Apr 08, 2005 at 04:57:11PM +0200, Rao Davide wrote:
My name is David Rao and I have an old alpha DS10 ds10 (ev6
Tsunami-webbrick cpu) with internal HDU on a LSI controller and external
HSZ80 storage attached to a Qlogic.
Well, the CONFIG_SCSI_QLOGIC_ISP driver isn't supported, and
On Sat, Apr 09, 2005 at 03:46:12PM -0700, David S. Miller wrote:
On Sat, 09 Apr 2005 19:22:23 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
ppc64 already has a local_irq_save/restore in switch_to, around the low
level asm bits, so it should be fine.
Sparc64 essentially does as
On Mon, Apr 18, 2005 at 02:48:41PM +0200, Rao Davide wrote:
Is LVM working on the alpha port 2.6 kernel series ?
I have no idea. I've no use for the thing myself.
r~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Mon, Feb 07, 2005 at 05:20:06PM -0800, Linus Torvalds wrote:
+3: movl %eax,(%ecx)
...
+3: movl %eax,(%ecx)
+4: movl %edx,4(%ecx)
...
+ .long 3b,bad_put_user
+ .long 4b,bad_put_user
The first 3 gets lost.
r~
-
To unsubscribe from this list: send the line unsubscribe
On Mon, Feb 07, 2005 at 05:20:06PM -0800, Linus Torvalds wrote:
+#define __put_user_8(x, ptr) __asm__ __volatile__(call __put_user_8:=A
(__ret_pu):0 ((typeof(*(ptr)))(x)), c (ptr))
This is not constrained enough. The compiler could choose to put the
return value in edx. You want
__asm__
On Tue, Feb 08, 2005 at 06:27:08PM -0800, Linus Torvalds wrote:
That brings up another issue: if I don't care which registers a 64-bit
value goes into, can I get the low reg and high reg names some way?
Nope. We never needed one in the i386 backend itself, so we never
added anything like
On Tue, Feb 08, 2005 at 06:16:15PM -0800, Linus Torvalds wrote:
I'd happily use your version, but I thought that some versions of gcc
require that input output registers cannot overlap, and would refuse to do
that thing? But if you tell me differently..
No, you're thinking of
asm( :
On Fri, Apr 29, 2005 at 10:44:17AM +1000, Paul Mackerras wrote:
You have made semaphores bigger and slower on the architectures that
have load-linked/store-conditional instructions, which is at least
ppc, ppc64, sparc64 and alpha.
And mips.
While sparc64 doesn't have ll/sc, it does have
On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
+/* TODO: integrate with include/asm-generic/pci.h ? */
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+ return channel ? 15 : 14;
+}
Am I missing something, or is this *only* used by
On Sat, Mar 19, 2005 at 03:39:33PM -0500, Jeff Garzik wrote:
Don't send this patch upstream until its been verified to actually work.
It certainly won't. I'll gen up something soon.
r~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Sun, Mar 20, 2005 at 07:03:52PM -0800, Andrew Morton wrote:
Dan Kegel [EMAIL PROTECTED] wrote:
Anyone with an alpha care to suggest a fix for this?
arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used
On Sun, Mar 20, 2005 at 07:03:52PM -0800, Andrew Morton wrote:
Dan Kegel [EMAIL PROTECTED] wrote:
Anyone with an alpha care to suggest a fix for this?
arch/alpha/kernel/srmcons.c: In function 'srmcons_open':
arch/alpha/kernel/srmcons.c:196: warning: 'srmconsp' may be used
On Mon, Mar 21, 2005 at 02:52:10PM +, Alan Cox wrote:
The issue is bigger - it's needed for the CMD controllers on PA-RISC for
example it appears - and anything else where IDE legacy IRQ is wired
oddly.
Sure, but who queries this information? That's my question.
r~
-
To unsubscribe from
On Tue, Mar 22, 2005 at 01:01:45PM -0800, Andrew Morton wrote:
I had the impression Richard planned on something more sophisticated
than this??
Indeed. I suppose I can pass it along to avoid repeated it doesn't build
messages, but an smp kernel doesn't run. *All* processes spawned by init(1)
On Mon, Jan 24, 2005 at 03:16:36PM -0800, Edward Peschko wrote:
cool.. any chance for some syntactic sugar so me (and other
users/vendors) wouldn't need to change any of their build scripts
and compilation processes?
Uh, like what? That's about as simple as you can get.
r~
-
To
On Mon, Jan 24, 2005 at 02:24:49PM -0800, Edward Peschko wrote:
What I'd like to do is be able to set up my LD_LIBRARY_PATH
so that I can reference it from the point of view of the
*executable*:
setenv LD_LIBRARY_PATH */../lib:.
Here, read * == full path of dirname of
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines. These routines have
their address
1 - 100 of 397 matches
Mail list logo
