Compile bombs out in bridging:
br.c: In function `brg_probe':
br.c:2458: `loops_per_sec' undeclared (first use in this function)
br.c:2458: (Each undeclared identifier is reported only once
br.c:2458: for each function it appears in.)
br.c:2442: warning: `bogomips' might be used uninitialized in
On Sat, 30 Sep 2000, Horst von Brand wrote:
> Alexander Viro <[EMAIL PROTECTED]> said:
>
> [...]
>
> > Patches are welcome. But keep in mind that we _are_ dependent on a
> > particular compiler. gcc, that is. I would be glad to get rid of it - the
> > codebase is extremely messy. However,
There is no need for a law requiring a 'standard' kernel in any
distro, and there is no chance people would follow any such rule.
So long as people know their distro kernel is patched and, if they
want to apply some 3rd party patch, we advise them they may want to
obtain and install 'clean'
Hi,
I am trying to call execve() from within fs/binfmt_elf.c. I am fairly
certain I am giving it the right arguments (ie. path,argv and envp). As an
example I am referring to the use of execve in kernel/kmod.c and
init/main.c. On kernel compilation I always get the error
"Warning:
>
> Attached is my .config, not sure what else could be needed.
>
>
Patience :) In Alan's announce, he said some changes were made to udelay()
that would require non-x86
Alexander Viro <[EMAIL PROTECTED]> said:
[...]
> Patches are welcome. But keep in mind that we _are_ dependent on a
> particular compiler. gcc, that is. I would be glad to get rid of it - the
> codebase is extremely messy. However, removing gcc-isms is a huge
> work. You are welcome to do it,
This is the first time in a long time I'm experiencing problems with
the Linux kernel. A wonderful job. The backside is that it's also a
very long time ago since the last time I read (parts of) the kernel.
One of my users complained of netscape hanging frequently while
reading news. I tried to
Bernhard Rosenkraenzer wrote:
> > Which still makes it an broken, experimental, unreleased and unofficial
> > compiler, with all the consequences I said.
>
> I agree about the "unreleased and unofficial" part, but it's not quite
> that broken and experimental. Everything that is shipped with Red
> that the main kernel is compiled with gcc, and linked with standard ld,
> and only the bootloader code is compiled using the bin86 (as86,
> ld86) tools. Am I right in interpreting this to mean that the main kernel
> is/can be 32-bit binary, and not strictly 16-bit?
The main kernel is 32bit.
Andre Hedrick wrote:
>
> On Sat, 30 Sep 2000, Alex Stewart wrote:
>
> > The attached patch (against 2.4.0-test8) adjusts the code to only mark
> > the slave not present if a flashdisk is master, not vice-versa.
>
> So are you saying that the master is flash and slave is ATA?
No, that's not
I was perusing the makefiles, and I've pretty much come to the conclusion
that the main kernel is compiled with gcc, and linked with standard ld,
and only the bootloader code is compiled using the bin86 (as86,
ld86) tools. Am I right in interpreting this to mean that the main kernel
is/can be
In article <[EMAIL PROTECTED]>,
Marc Lehmann <[EMAIL PROTECTED]> wrote:
>Taken on it's own, redhat never did anything which is not "politically
>correct" or "was just a bug that has been fixed". However, that redhat
>claims to maintain linux, gcc and other major projects (which is
>absolutely
Don Becker has some text at:
http://www.scyld.com/expert/irq-conflict.html
which includes a section:
> Why SA_INTERRUPT in the SCSI drivers is a Bad Thing
> ... it could potentially have a very negative impact on all other interrupt-driven
> kernel service. That includes just about everything
On Sat, Sep 30, 2000 at 08:23:37PM -0500, Peter Samuelson wrote:
>
> [Matthew Wilcox]
> > if fcntl took a 4th argument specifying the length of the buffer, i'd
> > recommend a F_GETLKS fcntl. a horrid work around for this would be
> > that the first 4 bytes of the buffer pointed to by the third
On Tue, 29 Feb 2000 11:10:20, Mikulas Patocka wrote:
: This code in breada
:
:if (blocks < (read_ahead[MAJOR(dev)] >> index))
:blocks = read_ahead[MAJOR(dev)] >> index;
:
: will increase number of block that are read ahead. However the code
: doesn't check for end of
[Christoph Hellwig]
> If you are using a distribution that ships with a default C compiler
> that is not able to compile linux kernel, use make CC=kgcc (redhat)
> or CC=gcc272 (debian) instead.
That works for >= 2.3.30 or so. For 2.2 it's more like
make CC="kgcc -D__KERNEL__
[Matthew Wilcox]
> if fcntl took a 4th argument specifying the length of the buffer, i'd
> recommend a F_GETLKS fcntl. a horrid work around for this would be
> that the first 4 bytes of the buffer pointed to by the third argument
> of the fcntl is the length of the buffer.
E! You're
On Sun, Oct 01, 2000 at 12:55:30AM +0100, Alan Cox wrote:
> > When debugging this kind of problem, you're not interested in the
> > non-conflicting locks, only the ones which are blocked waiting for
> > another lock, right?
>
> All I care about is what locks are currently in force in the system.
On Sat, 30 Sep 2000, Mr. James W. Laferriere wrote:
> Where does the idea that the kernel 'needs' a special compiler
> come from ? I have been under the impression that that is just
Mostly from the sad fact that it does.
> what we were trying to get away from . I am
> > Isn't this completely broken? I mean, it wont detect the others at all. It
> > will leave CC="" if gcc272 or kgcc are there.
>
> Yes. Sorry I' too selfish today ;) Your version seems more accurate to me.
I've dropped Miquel's version into my tree. He simply side steps the entire
'which
> come from ? I have been under the impression that that is just
> what we were trying to get away from . I am reminded of other
> os's that required their propritary compiler in order to create
> a os image . Please let us not travel that road . Tia , JimL
We've
Ben Collins <[EMAIL PROTECTED]> wrote:
> Isn't this completely broken? I mean, it wont detect the others at all. It
> will leave CC="" if gcc272 or kgcc are there.
Yes. Sorry I' too selfish today ;) Your version seems more accurate to me.
Christoph
--
Always remember that you are
> When debugging this kind of problem, you're not interested in the
> non-conflicting locks, only the ones which are blocked waiting for
> another lock, right?
All I care about is what locks are currently in force in the system. So for
example I can do something like
showlocks
On Sat, Sep 30, 2000 at 07:30:42PM -0400, Alexander Viro wrote:
> Forget distributions. There is a very, very good reason to have the choice
> of cc used in kernel builds uncoupled from the userland one. IMO kgcc is a
> misnomer (kcc would be better), but the idea is sound - you don't want to
>
Hello Alexander ,
On Sat, 30 Sep 2000, Alexander Viro wrote:
> On Sun, 1 Oct 2000, Christoph Hellwig wrote:
> > I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot,
> > and I think we should put a sentence like
> > If you are using a distribution that ships with
On Sat, 30 Sep 2000, Alex Stewart wrote:
> The attached patch (against 2.4.0-test8) adjusts the code to only mark
> the slave not present if a flashdisk is master, not vice-versa.
So are you saying that the master is flash and slave is ATA?
Did you read the ide.c about ()->ata_flash flags?
All
On Sun, Oct 01, 2000 at 12:29:27AM +0100, Alan Cox wrote:
> > Does anyone actually want /proc/locks to stay? The data structure
>
> I'd like a way to view the locks that exist - its useful for debugging
> weird app stuff
>
> > out /proc/locks. If it could be deleted, a lot of code and data
On Sun, 1 Oct 2000, Alan Cox wrote:
> If it makes the code far cleaner then I have no objection. If we can do a
> simple (different format even) /proc/locks to replace it that scores double
> points ;)
Additional bonus points for changing the name. /proc/fs/locks might be a
good variant...
-
On Sun, 1 Oct 2000, Christoph Hellwig wrote:
> I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot,
> and I think we should put a sentence like
>
> If you are using a distribution that ships with a default C compiler that is
> not able to compile linux kernel, use
> - snip -
>
> --- Makefile~ Sun Oct 1 00:46:27 2000
> +++ Makefile Sun Oct 1 00:49:27 2000
> @@ -23,7 +23,7 @@
> AS =$(CROSS_COMPILE)as
> LD =$(CROSS_COMPILE)ld
> CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)cc; else \
> - which gcc272 2>/dev/null
> Does anyone actually want /proc/locks to stay? The data structure
I'd like a way to view the locks that exist - its useful for debugging
weird app stuff
> out /proc/locks. If it could be deleted, a lot of code and data pointers
> could go away. I don't think any program depends on its
Does anyone actually want /proc/locks to stay? The data structure
which allows it to be generated is now only used by the code to print
out /proc/locks. If it could be deleted, a lot of code and data pointers
could go away. I don't think any program depends on its existance and
it's a pretty
On Sat, 30 Sep 2000, Alan Cox wrote:
> > use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2
> > mouse and do I want to install it, etc. If I tell it not to change
> > anything, the system comes up. However, the real mouse then misbehaves
> > badly, losing button-down
> I personally dislike the 'autmatically detect kgcc and gcc272' patches a lot,
> and I think we should put a sentence like
>
> If you are using a distribution that ships with a default C compiler that is
> not able to compile linux kernel, use make CC=kgcc (redhat) or CC=gcc272
> (debian)
> o Fix the 'which' compiler stuff (Horst von Brand,
>Peter Samuelson)
> | Can someone verify for me this works on Slackware and
> | on Caldera ?
It breaks on Caldera.
The errors are:
-- snip -
Attached is a patch which fixes the boot problems on I-Opener hardware.
The problem is not the IDE chipset, as some had assumed, but rather the
SanDisk flash disk. Since flashdisks typically don't have slaves, there
is code in the kernel to avoid checking for a slave disk if a flashdisk
is
On Sat, 30 Sep 2000, Alan Cox wrote:
> > does not compile with gcc272.
> >
> > It complains about the line
> >
> > static __attribute__((unused)) void unused(void)
> >
> > gcc 2.95.2 does compile it.
>
> I dont have 272 around at the moment does
>
> static void __attribute__((unused)) work ?
On Sat, Sep 30, 2000 at 03:13:02PM +0100, Alan Cox wrote:
> > Please replace which with "command -v" which is required by SuS in /bin/sh.
>
> command -v breaks on some setups. One problem can be seen easily by doing this
>
> # command -v ls
> alias ls='ls --color=tty'
.bashrc is only read for
On Sat, 30 Sep 2000, Alan Cox wrote:
> > use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2
> > mouse and do I want to install it, etc. If I tell it not to change
> > anything, the system comes up. However, the real mouse then misbehaves
> > badly, losing button-down
For anyone wanting to track the MANOS fork of Linux for the purposes of
monitoring bugs that show up in the ports of Linux code and drivers to
the Open Source NetWare, the MANOS mailing list is active, and you can
sign up at [EMAIL PROTECTED] It's set up the same way the
lists for linux-kernel
On Sat, 30 Sep 2000, Michael Peddemors wrote:
>On Sat, 30 Sep 2000, Marc Lehmann wrote:
>
>> However, I think attacking other free softwrae projects because of *bugs*
>> is just childish at this point - after all, this discussion was about
>> supporting distributions that - without technical
Linus, lkml,
The following patch is required so that munmap(0x8000, *) does not cause
ARM kernels to hang. The problem is that the machine vectors are at
virtual address 0. Unfortunately, when free_pgtables() is called, it
clears first level page tables starting at 0 in this case, and takes
Bug squash number one. This should fix the 'it doesnt compile at all' bug.
The other change here is that support for faster processors, that will catch
out anyone using (abusing) udelay with extremely large values. If you get
a link error or a module load error about bad_udelay let me know.
> 'Standard Linux'
> Should the core kernel define a standard Linux??
To an extent.
I will tell you the rules I try to follow for 2.2.x
o Never add an ABI that is not standardised in 2.3.x by Linus
o If drivers/ioctl interfaces are added to 2.2 first I try to be very
On Sat, Sep 30, 2000 at 10:57:57PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> > they were involved, but I have reason to doubt that they actually agreed.
>
> They did.
O.k. let's disagree ;)
> > This really is an affront on your side, twisting reality quite a bit - the
> I noticed you
On Sat, 30 Sep 2000, Michael Peddemors wrote:
> ie should we say that ALL distros have to ship with, and be compatible with the
> standard kernel? If a distro has a patch that they want in the kernel, and the
> mainstream kernel doesn't feel it belongs, should it be labeled differently?
> Do
> use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2
> mouse and do I want to install it, etc. If I tell it not to change
> anything, the system comes up. However, the real mouse then misbehaves
> badly, losing button-down events and being generally sluggish.
>
> Rebooting
I didn't try -test8 since it's LFS seems broken. But anyway, I was able to
crash a machine using ramfs when I filled it up. I got "Kernel panic:
attempted to kill init" on the console
--
Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send
> does not compile with gcc272.
>
> It complains about the line
>
> static __attribute__((unused)) void unused(void)
>
> gcc 2.95.2 does compile it.
I dont have 272 around at the moment does
static void __attribute__((unused)) work ?
-
To unsubscribe from this list: send the line
> > 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.
They did.
> > to the temporary ABI in 2.95 first -
On Sat, Sep 30, 2000 at 02:39:00PM -0700, Michael Peddemors <[EMAIL PROTECTED]> wrote:
> That RedHat Thread was degrading into a name calling match...
And a pile of misunderstandings as well.
> ie should we say that ALL distros have to ship with, and be compatible with the
> standard kernel?
On Sat, 30 Sep 2000, Marc Lehmann wrote:
> However, I think attacking other free softwrae projects because of *bugs*
> is just childish at this point - after all, this discussion was about
> supporting distributions that - without technical reasons - make their
> products incompatible to what
On Sat, 30 Sep 2000, Nix wrote:
>Andries Brouwer <[EMAIL PROTECTED]> writes:
>
>> On Sat, Sep 30, 2000 at 03:09:10PM +0100, Nix wrote:
>>
>> > Yesterday, I noticed that netstat had stopped working on my 2.2.17 box
>> > The reason is fairly self-evident:
>> >
>> > : loki:/# cat /proc/net/dev
>>
Just FYI; I tried to reply to your mail (you know the topic) but your
mailserver blocked me. I didn't ignore that mail.
-
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 http://www.tux.org/lkml/
On Sat, Sep 30, 2000 at 01:20:58PM -0700, Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> > If you say so However, I am not sure that you (we?) can actually
> > control it.
>
> You are excused this one and only time since I am fortunate enough to
> never have met you but listen carefully now:
Alan,
I just jumped to 2.2.18pre12 from 2.2.17 final. Something's broken with
mouse detection. My mouse is a Logitech Serial Mousman on ttyS0, and has
been forever. A ps/2 port is present on the motherboard, but not in
use. At boot of 2.2.18pre12, kudzu announces that it's found a new PS2
I really didn't want to make a comment on this stupid thread but now
you are getting personal:
> > > OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible
> > > changes,
> >
> > We're doing no such thing.
>
> If you say so However, I am not sure that you (we?) can actually
In 2.4.0-test9-pre7, uhci module does not reliably. I have a Logitech
N48 wheel mouse attached, it's the only USB device. I can use the mouse
fine in X via /dev/input interface (except that input moule's reference
count is still zero). But when I switch to text console (and maybe move
the mouse)
Hello,
drivers/char/drm/r128_drv.c
does not compile with gcc272.
It complains about the line
static __attribute__((unused)) void unused(void)
gcc 2.95.2 does compile it.
Greetings,
Wolfgang Walter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > recheck and found a strange thing: lsmod shows zero usage counts for usb
> > modules while I'm actively using the mouse in X.
>
> Using the input device (dev/input/.. ) ?
Yes, "mknod /dev/input/mice c 13 63" and X uses it happily.
Just noticed that it's the same under 2.4.0-test9-pre7.
>
On Sat, Sep 30, 2000 at 09:28:18PM +0200, Bernhard Rosenkraenzer <[EMAIL PROTECTED]>
wrote:
> > OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible
> > changes,
>
> We're doing no such thing.
If you say so However, I am not sure that you (we?) can actually
control it.
>
Andries Brouwer <[EMAIL PROTECTED]> writes:
> On Sat, Sep 30, 2000 at 03:09:10PM +0100, Nix wrote:
>
> > Yesterday, I noticed that netstat had stopped working on my 2.2.17 box
> > The reason is fairly self-evident:
> >
> > : loki:/# cat /proc/net/dev
> ...
> > : lo:%lu %lu %lu %lu %lu %lu
On Sat, Sep 30, 2000 at 08:08:40PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> for Caldera, Transmeta, SuSE and others I expect. So I dont think you can
> work on the basis they have any influence over me.
The logic is not quite right, but tt's definitely another story indeed.
> > the largest
On Sat, 30 Sep 2000, Marc Lehmann wrote:
> OTOH, [EMAIL PROTECTED] might get pressed into not doing incompatible
> changes,
We're doing no such thing.
If we did this sort of thing, he would have been pressed into releasing
glibc 2.2 in time.
[EMAIL PROTECTED] did have some influence on choosing
Hello Thomas !
I've slightly enhanced the bonding code :
- MII link checking with automatic slave enabling/disabling :
Now the bond interface monitors all its MII-compliant slaves
and disables the ones which have a dead link, and enables those
which have a good one. The link check
On Fri, 29 Sep 2000, Alec Smith wrote:
> Congratulations, you got further than I did. I couldn't even get that
> disaster known as RH7.0 to even install. It died with some error about not
> being able to detect free disk space after formatting the paritions...
Please report this at
On Fri, 29 Sep 2000, David M. Rector wrote:
> Has anyone tried Redhat 7.0 yet?
Sure...
> What a mess.
Not quite...
> 1) It would not compile stock kernels out of the box. (ends at
> compress.S) with a fatal error.
Either use the kernel compiler (kgcc) or patch the file to be compatible
with
> recheck and found a strange thing: lsmod shows zero usage counts for usb
> modules while I'm actively using the mouse in X.
Using the input device (dev/input/.. ) ?
> input 3068 0 [mousedev usbmouse]
This appears to be the problem, the others are all locked by being used
Hi.
I recently had a problem with linux 2.2.x and 2.4.0 oopsing early
in the boot process on a old pentium I had gotten hold of. printk
investigation showed the problem to be in the PCI detection code,
specifically the part where linux tries to go through the BIOS to
get the PCI settings.
> After all, even if you do work for redhat, the way redhat actively damages
I work for Red Hat. I can pick up the phone any day of the week and work
for Caldera, Transmeta, SuSE and others I expect. So I dont think you can
work on the basis they have any influence over me.
> same) and free
> There are also many assembler warnings. Most talk about using %eax where
> %ax was asked with l suffix. Also some indirect lcalls without *. Proably
> not dangerous.
These are intentional. Actually fixing them breaks building with older
binutils 8(
Alan
-
To unsubscribe from this list: send
On Sat, 30 Sep 2000, James Cownie wrote:
> I was expecting to take the Posix thread style viewpoint in which any
> of the core dumping signals kill the _process_, so all of the threads
> are necessarily dead thereafter since they have nowhere to live any
> longer.
Different model. Threads are
On Sat, 30 Sep 2000, Marc Lehmann wrote:
> Which still makes it an broken, experimental, unreleased and unofficial
> compiler, with all the consequences I said.
I agree about the "unreleased and unofficial" part, but it's not quite
that broken and experimental. Everything that is shipped with
Just as I said that 2.2.18pre12 works well with my usb mouse, I did
recheck and found a strange thing: lsmod shows zero usage counts for usb
modules while I'm actively using the mouse in X.
Module Size Used by
ide-cd 23928 1 (autoclean)
cdrom
On 30 Sep 2000 15:09:10 +0100,
Nix <[EMAIL PROTECTED]> wrote:
>: loki:/# cat /proc/net/dev
>: Inter-| Receive| Transmit
>: face |bytespackets errs drop fifo frame compressed multicast|bytespackets
>errs drop fifo colls carrier
(no complaints about 2.2.18pre12 from real work - my usb mouse works
well).
* make xconfig gave 2 errors:
ERROR - Attempting to write value for unconfigured variable (CONFIG_VIDEO_CPIA_USB).
ERROR - Attempting to write value for unconfigured variable (CONFIG_USB_AUDIO).
* there were many
On Sat, Sep 30, 2000 at 07:30:50PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> pgcc just didnt work. I got to the point where the kernel list stuff I had
> actually had pgcc filtered. Because it was kernel crash pgcc this, kernel
> wont compile pgcc that.
Well, I grant that supporting pgcc is
Jeff Garzik wrote:
>
> On 29 Sep 2000, H. Peter Anvin wrote:
> > Followup to: <[EMAIL PROTECTED]>
> > By author:Andries Brouwer <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > On Thu, Sep 28, 2000 at 03:41:41PM -0700, Jack Howarth wrote:
> > >
> > > > I find that the
> pgcc never was incompatible at binary level to gcc/egcs.
pgcc just didnt work. I got to the point where the kernel list stuff I had
actually had pgcc filtered. Because it was kernel crash pgcc this, kernel
wont compile pgcc that.
> That's simply a fact that you can't discuss away by
On Sat, 30 Sep 2000, Andrea Arcangeli wrote:
> On Sat, Sep 30, 2000 at 02:58:35PM -0300, Rik van Riel wrote:
> > Both the current code and classzone will need some adjustments
> > to work fine (as in: reasonably efficient) with NUMA.
>
> The exact thing I was talking about in my previous email
On Sat, Sep 30, 2000 at 04:26:38PM +0100, Alan Cox wrote:
> > > They released a supported ex-Cygnus people approved compiler.
> >
> > Which still makes it an broken, experimental, unreleased and unofficial
> > compiler, with all the consequences I said.
>
> And didnt you write something called
On Sat, Sep 30, 2000 at 02:58:35PM -0300, Rik van Riel wrote:
> Both the current code and classzone will need some adjustments
> to work fine (as in: reasonably efficient) with NUMA.
The exact thing I was talking about in my previous email is that in classzone
_all_ the cache lru are been
Carsten Lang <[EMAIL PROTECTED]> writes:
> Hi,
> i don't want to start discussing the pros and cons of using C++ in kernel
> development.
> BUT: why do we blame people if they want to?
several reasons
1) this thread keeps coming back on linux-kernel and various linux
related usenet
On Sat, 30 Sep 2000, Timothy Little wrote:
> >> When using ide-scsi to access a CDRW writer, the recording process works
> >> but I am not able to mount any CD-ROM media in that drive for reading.
> >
> >And here it's exactly the opposite :)
> >
> >If anyone has a Philips CDD-36xx drive and
On Sat, 30 Sep 2000, Andrea Arcangeli wrote:
> The allocator also mandatory needs part of classzone to be able
> to make decent decisions. (putting the memory of different NUMA
> nodes internally to a pgdat_t as different zones as it's been
> proposed in linux-mm is a broken hack that can't work
On Sat, Sep 30, 2000 at 12:14:56PM -0500, [EMAIL PROTECTED] wrote:
> I do appreciate the many responses I've received to my initial query. I'm
> glad that there *is* a solution that allows me read/write one hardsector,
> and I'll be implementing such in my EFI partition code after the weekend.
>
I do appreciate the many responses I've received to my initial query. I'm
glad that there *is* a solution that allows me read/write one hardsector,
and I'll be implementing such in my EFI partition code after the weekend.
As for the issue of understanding a drive's true capacity and
> "anton" == Anton Blanchard <[EMAIL PROTECTED]> writes:
>> > 2nd Question: Is there a sane way to queue an operation to be done in
>> >each specific CPU?
>>
>> smp_call_function().
anton> The slab code was using smp_call_function until davem fixed it.
anton> On sparc
On Fri, Sep 29, 2000 at 11:41:57PM +1100, Anton Blanchard wrote:
> On sparc blocking interrupts does not block the reception of cpu cross
> calls, so you cannot do anything like grab locks within a called function.
So if you can't handle the IPI when you get it, set a flag and trap on the
next
On Sat, 30 Sep 2000, Vojtech Pavlik wrote:
> That, again, is the IDE driver issue, not the FS layer's. If you want to
Nope it is a SCSI issues also.
If it was not Matt would not be asking the question.
I have more of a heads up on what he was wanting because I spoke with him
for about 45 min on
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>I'll play with the proposed which based fixes first, unless you have clever
>ideas ?
Include a script in scripts/kwhich that tells you the path to
a certain binary.
Below is a simple implementation. If you condense it you can
Hello!
> The slab code was using smp_call_function until davem fixed it.
>
> On sparc blocking interrupts does not block the reception of cpu cross
> calls, so you cannot do anything like grab locks within a called function.
Funny, are IPI really absolute nmi on sparc? I am honestly curious,
On Sat, Sep 30, 2000 at 04:26:38PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Which still makes it an broken, experimental, unreleased and unofficial
> > compiler, with all the consequences I said.
>
> And didnt you write something called pgcc once.
Oh yes, of course while providing full
On Sat, Sep 30, 2000 at 03:45:54PM +0100, James Cownie wrote:
> Since the Villarreal patch exists and seems to do all that I wanted, I
> don't propose to create a competing patch.
>
> Maybe you kernel gurus could point out any problems with the Villarreal
> approach ?
The patch assumes that
> > They released a supported ex-Cygnus people approved compiler.
>
> Which still makes it an broken, experimental, unreleased and unofficial
> compiler, with all the consequences I said.
And didnt you write something called pgcc once.
*PLONK*
Alan
-
To unsubscribe from this list: send the
On Sat, Sep 30, 2000 at 03:58:20PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> > a broken, experimental, unreleased compiler as if it were an official
> > version. Worse, creating a maintainance nightmare for almost everybody by
>
> They released a supported ex-Cygnus people approved compiler.
> projects because they receive bogus bug reports because redhat shipped
> a broken, experimental, unreleased compiler as if it were an official
> version. Worse, creating a maintainance nightmare for almost everybody by
They released a supported ex-Cygnus people approved compiler. Its not the
> Open question: whether or not to allow the remaining threads to
> continue once the dump is completed, to abort them, or to signal
> them. Probably should be run time configurable.
I was expecting to take the Posix thread style viewpoint in which any
of the core dumping signals kill the
On Wed, Sep 27, 2000 at 12:18:11PM +, Pavel Machek wrote:
> Hi!
>
> > Well, I'm finally getting around to sending out this announcement.
> > As can be seen on www.alphanews.net, we've managed to boot Linux on an
> > AlphaServer GS320. The only caveats are that one of the CPUs was out of
On Sat, Sep 30, 2000 at 03:07:49PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> > If you don't like this, I suggest you send mail complaining to RedHat.
> > Customer complaints are going to be the only way that RH is going to be
> > influenced not to play games like this
>
> Remind me next
1 - 100 of 284 matches
Mail list logo
