(I'm replying to a message from about a month ago, but it's relevant to a
problem I'm having now.)
[EMAIL PROTECTED] wrote:
>Date: Mon, 09 Oct 2000 20:13:35 +0200
>From: Thomas Sailer <[EMAIL PROTECTED]>
>
[snip]
>My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the
>
(I'm replying to a message from about a month ago, but it's relevant to a
problem I'm having now.)
[EMAIL PROTECTED] wrote:
Date: Mon, 09 Oct 2000 20:13:35 +0200
From: Thomas Sailer [EMAIL PROTECTED]
[snip]
My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the
s. Note that we
don't have such a problem for MMIOs fortunately ;)
Ben.
-- RFC822 Header Follows --
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
To: Martin Mares <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: FIXED! Updated 2.4 TODO List --
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
> It may work, but the bridge secondary/subordinate numbers look wrong.
>
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses...
Hi Jeff!
> First, some definitions:
> downstream - away from the host processor
> primary - number of the PCI bus closer to the host processor
> secondary - number of the PCI bus on the downstream side of the PCI
> bridge
> subordinate - number of the highest-numbered bus on the downstream side
Hi Jeff!
First, some definitions:
downstream - away from the host processor
primary - number of the PCI bus closer to the host processor
secondary - number of the PCI bus on the downstream side of the PCI
bridge
subordinate - number of the highest-numbered bus on the downstream side
of
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
It may work, but the bridge secondary/subordinate numbers look wrong.
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
Ben.
-- RFC822 Header Follows --
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
To: Martin Mares [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI
resourcecollisions (fwd)
Date: Thu, 26 Oct 2000 14:3
hi kernelList,
i readed this thread and had the hope that it will fix my problem.
i have an older quad 166Mhz ppro machine with an intel mainbord.
it runs only with kernel command NOAPIC.
tried kernels from 2.2.15 to 2.4.0-test9.
with apic, it will boot till init of the first adaptecController
It may work, but the bridge secondary/subordinate numbers look wrong.
I am pondering if the bus numbering/bridging stuff shouldn't be given a
good looking-over. I have the wonderful _PCI System Architecture, 4th
Ed._ in my hands, and it describes PCI-PCI bridge init in great detail,
including
Cool.
On Wed, 25 Oct 2000, jamal wrote:
>
> The problem is resolved. Mucho Gracias from me and a few (probably
> hundreds of people in my workplace) who might want to boot 2.3/4 on these
> Dell docking stations (actually we own a few thousand of them, i am just
> trying to make sure Linux
On 24 Oct 2000, Eric W. Biederman wrote:
> "David S. Miller" <[EMAIL PROTECTED]> writes:
> >
> > I bet PCI allows no such thing, thus to be totally safe I would
> > conditionalize this feature on the specific bridge. Ie. only allow
> > it for this bridge type, because I bet it is just some
On Wed, Oct 25, 2000 at 12:20:58PM -0400, jamal wrote:
> + child->resource[0,1,2] = dev->bus->resource[0,1,2];
Did C change while I was asleep, or is this statement equivalent to
child->resource[2] = dev->bus->resource[2];
?
Jeff
-
To unsubscribe from this list:
The problem is resolved. Mucho Gracias from me and a few (probably
hundreds of people in my workplace) who might want to boot 2.3/4 on these
Dell docking stations (actually we own a few thousand of them, i am just
trying to make sure Linux runs fine ;->)
The proper fix, which is i think what
Hello!
[Sorry for the delay, I've been ill for two weeks and now I'm trying hard
to catch up with the huge pile of mail...]
> I'm not certain of the details but I do know that it is legal.
> To date I've only heard of it on ISA bridges, in particular the PIIXE.
> It's some kind of passive
The problem is resolved. Mucho Gracias from me and a few (probably
hundreds of people in my workplace) who might want to boot 2.3/4 on these
Dell docking stations (actually we own a few thousand of them, i am just
trying to make sure Linux runs fine ;-)
The proper fix, which is i think what
On Wed, Oct 25, 2000 at 12:20:58PM -0400, jamal wrote:
+ child-resource[0,1,2] = dev-bus-resource[0,1,2];
Did C change while I was asleep, or is this statement equivalent to
child-resource[2] = dev-bus-resource[2];
?
Jeff
-
To unsubscribe from this list: send the
It may work, but the bridge secondary/subordinate numbers look wrong.
I am pondering if the bus numbering/bridging stuff shouldn't be given a
good looking-over. I have the wonderful _PCI System Architecture, 4th
Ed._ in my hands, and it describes PCI-PCI bridge init in great detail,
including
hi kernelList,
i readed this thread and had the hope that it will fix my problem.
i have an older quad 166Mhz ppro machine with an intel mainbord.
it runs only with kernel command NOAPIC.
tried kernels from 2.2.15 to 2.4.0-test9.
with apic, it will boot till init of the first adaptecController
On 24 Oct 2000, Eric W. Biederman wrote:
"David S. Miller" [EMAIL PROTECTED] writes:
I bet PCI allows no such thing, thus to be totally safe I would
conditionalize this feature on the specific bridge. Ie. only allow
it for this bridge type, because I bet it is just some bug in the
Cool.
On Wed, 25 Oct 2000, jamal wrote:
The problem is resolved. Mucho Gracias from me and a few (probably
hundreds of people in my workplace) who might want to boot 2.3/4 on these
Dell docking stations (actually we own a few thousand of them, i am just
trying to make sure Linux runs
Hello!
[Sorry for the delay, I've been ill for two weeks and now I'm trying hard
to catch up with the huge pile of mail...]
I'm not certain of the details but I do know that it is legal.
To date I've only heard of it on ISA bridges, in particular the PIIXE.
It's some kind of passive
"David S. Miller" <[EMAIL PROTECTED]> writes:
>Date: Tue, 24 Oct 2000 13:50:10 -0700 (PDT)
>From: Linus Torvalds <[EMAIL PROTECTED]>
>
>Does the above make it work for you? I don't know if PCI even has
>the notion of transparent bridging, and quite frankly I doubt it
>
On Tue, 24 Oct 2000, jamal wrote:
>
> (Now that i see Martin alive).
> Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0
ares <[EMAIL PROTECTED]>
Subject: Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource
collisions (fwd)
Sorry for the delay, the docking station in question is a few kilometers
away.
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> And I don't find any code that would ever h
]
Subject: Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource
collisions (fwd)
Sorry for the delay, the docking station in question is a few kilometers
away.
On Fri, 13 Oct 2000, Linus Torvalds wrote:
And I don't find any code that would ever have done this, either. It must
On Tue, 24 Oct 2000, jamal wrote:
(Now that i see Martin alive).
Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0 -
"David S. Miller" [EMAIL PROTECTED] writes:
Date: Tue, 24 Oct 2000 13:50:10 -0700 (PDT)
From: Linus Torvalds [EMAIL PROTECTED]
Does the above make it work for you? I don't know if PCI even has
the notion of transparent bridging, and quite frankly I doubt it
does. The
Hi!
> While you should report drivers or other kernel functions
> that don't work, I don't think that just saying that
> something is broken is sufficient.
Well, that driver really is broken.
It uses tq_scheduler in strange way, so it has unbound ping times. (Up
to 20 seconds). It breaks under
Pavel,
While you should report drivers or other kernel functions
that don't work, I don't think that just saying that
something is broken is sufficient.
~Randy
> Hi!
>
> > 7. Obvious Projects For People (well if you have the hardware..)
> >
> > * Make syncppp use new ppp code
> > *
Pavel,
While you should report drivers or other kernel functions
that don't work, I don't think that just saying that
something is broken is sufficient.
~Randy
Hi!
7. Obvious Projects For People (well if you have the hardware..)
* Make syncppp use new ppp code
* Fix SPX
Hi!
While you should report drivers or other kernel functions
that don't work, I don't think that just saying that
something is broken is sufficient.
Well, that driver really is broken.
It uses tq_scheduler in strange way, so it has unbound ping times. (Up
to 20 seconds). It breaks under
Sorry for the delay, the docking station in question is a few kilometers
away.
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> And I don't find any code that would ever have done this, either. It must
> be somewhere, if 2.2 works for you.
>
I can put up the 2.2 bootup with DEBUG in pci.c if
Hi!
> 7. Obvious Projects For People (well if you have the hardware..)
>
> * Make syncppp use new ppp code
> * Fix SPX socket code
USB: plusb is b0rken.
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost
Hi!
7. Obvious Projects For People (well if you have the hardware..)
* Make syncppp use new ppp code
* Fix SPX socket code
USB: plusb is b0rken.
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy
On Fri, 13 Oct 2000, jamal wrote:
>
> This is in addition to the debug statements from the previous email
> Weirder results (like bus 0x0a)
Ok, thanks - this part didn't get anything new, the bus numbers are just
different due to the re-allocation, the actual bus windows are the same
broken
> > I agree. I would expect it to be 8 instead of 32.
> > Actually I just checked on a new Thinkpad T20 with a TI
> > PCI 1450 CardBus controller *on a different OS*
> > and it is 8.
>
> I'll fix it to be 8.
>
> Thanks,
>
> Linus
Well, preferably to what David said:
On Fri, 13 Oct 2000, Dunlap, Randy wrote:
>
> I agree. I would expect it to be 8 instead of 32.
> Actually I just checked on a new Thinkpad T20 with a TI
> PCI 1450 CardBus controller *on a different OS*
> and it is 8.
I'll fix it to be 8.
Thanks,
Linus
-
To unsubscribe
On Fri, 13 Oct 2000, jamal wrote:
>
> On Fri, 13 Oct 2000, Linus Torvalds wrote:>
> > Can you add the same extra debug code that I asked Dag Bakke to add for
> > his problem:
>
> Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular
> On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote:
> > I'm not familiar with yenta controllers/devices,
> > and I'm not trying to throw you a tasty red herring,
> > but...
> >
> > yenta_config_init() does
> > config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
> >
> > Is this
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Oh, also, can you try to see what happens if you change the define for
>
> #define pcibios_assign_all_busses() 0
>
> to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure
> all buses, regardless of whether they have
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
>
> -- snip from another email, because I'm lazy ---
>
> Please add a debug printk() to drivers/pci/setup-res.c to the very end of
> pci_assign_bus_resource(),
I have tested Linus' patch and it makes a difference:
cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
Found 06:00 [115d/0003] 000200 00
bus res 0 1200 1c00-1fff
bus res 1 200 2000-23ff
bus res 2 100 1800-18ff
bus res 0 1200 1c00-1fff
bus res 1 200
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote:
> I'm not familiar with yenta controllers/devices,
> and I'm not trying to throw you a tasty red herring,
> but...
>
> yenta_config_init() does
> config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
>
> Is this writing to the CardBus
I'm not familiar with yenta controllers/devices,
and I'm not trying to throw you a tasty red herring,
but...
yenta_config_init() does
config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
Is this writing to the CardBus bridge or to the device's
CacheLineSize register?
If the latter, and given
On Fri, 13 Oct 2000, Linus Torvalds wrote:
>
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
Oh, also, can you try to see what happens if you change the define for
#define pcibios_assign_all_busses() 0
to a 1 in include/asm-i386/pci.h?
On Thu, 12 Oct 2000, jamal wrote:
>
> I am attaching the debug output on bootup after defining DEBUG in pci.c
> and the i386 pci header file with test10-pre2
> Note: this is a Dell Lattitude docking station. The devices which are
> having resource problems are on the docking station. Works
On Fri, 13 Oct 2000, Dag Bakke wrote:
>
> This patch enables the expansion ROM, but it still doesn't make the card
> work.
Ok. It seems that your stuck bit is really stuck, and I was wrong: it's
not the cardbus bridge that does something strange, it actually looks like
your hardware has a
On Thu, 12 Oct 2000, jamal wrote:
I am attaching the debug output on bootup after defining DEBUG in pci.c
and the i386 pci header file with test10-pre2
Note: this is a Dell Lattitude docking station. The devices which are
having resource problems are on the docking station. Works fine
On Fri, 13 Oct 2000, Linus Torvalds wrote:
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
Oh, also, can you try to see what happens if you change the define for
#define pcibios_assign_all_busses() 0
to a 1 in include/asm-i386/pci.h? That
On Fri, 13 Oct 2000, Linus Torvalds wrote:
Oh, also, can you try to see what happens if you change the define for
#define pcibios_assign_all_busses() 0
to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure
all buses, regardless of whether they have been
On Fri, Oct 13, 2000 at 02:22:32PM -0700, Dunlap, Randy wrote:
I'm not familiar with yenta controllers/devices,
and I'm not trying to throw you a tasty red herring,
but...
yenta_config_init() does
config_writeb(socket, PCI_CACHE_LINE_SIZE, 32);
Is this writing to the
On Fri, 13 Oct 2000, jamal wrote:
On Fri, 13 Oct 2000, Linus Torvalds wrote:
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular docking
On Fri, 13 Oct 2000, Dunlap, Randy wrote:
I agree. I would expect it to be 8 instead of 32.
Actually I just checked on a new Thinkpad T20 with a TI
PCI 1450 CardBus controller *on a different OS*
and it is 8.
I'll fix it to be 8.
Thanks,
Linus
-
To unsubscribe from
I agree. I would expect it to be 8 instead of 32.
Actually I just checked on a new Thinkpad T20 with a TI
PCI 1450 CardBus controller *on a different OS*
and it is 8.
I'll fix it to be 8.
Thanks,
Linus
Well, preferably to what David said:
L1_CACHE_BYTES / 4
[EMAIL PROTECTED], Martin Mares <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]>
Subject: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource
collisions (fwd)
Ted,
Please add this to your list. Linux is unusable in these machines.
I have cc'ed Martin and Linus
On Thu, 12 Oct 2000 11:02:50 -0400,
"Chris Swiedler" <[EMAIL PROTECTED]> wrote:
>But the kernel should be able to write directly to the screen, even if it's
>extremely minimal information. Something like how LILO does it: test the
>common hang-on-boot conditions (like wrong CPU type) and print a
On Thu, 12 Oct 2000, Dag Bakke wrote:
>
> Linus,
> I realized there was one more test to do before deeming the hardware sane.
>
> PCMCIA (16-bit) in my laptop is tested and works fine with three different
> types of cards.
> Another Xircom card behaved just the same (non-functional) in my
On Thu, 12 Oct 2000, Keith Owens wrote:
> If anything is going to detect the mismatch and complain, it has to be
> the boot loader, after uncompressing and before entering the kernel
> proper.
Perhaps we can add the processor type to linux_banner and print it from
setup.S.
--
"Love the
> On Wed, 11 Oct 2000 18:10:40 -0400,
> [EMAIL PROTECTED] wrote:
> >Are you sure it was compiled with the correct CPU? If you configure the
> >CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
> >refuse to boot.
> >
> >Maybe we should have the kernel print the CPU
Cort Dougan <[EMAIL PROTECTED]> said:
> Horst von Brand on Wed, Oct 11, 2000 at 11:21:06PM -0400 said:
[...]
> } Oh, come on. The kernel (or glibc for that matter) is not about "inline
> } asm()" at all! That is a tiny fraction of each. The kernel is different in
> } that it has lots of
On Thu, Oct 12, 2000 at 06:26:57AM -0400, Horst von Brand wrote:
> [EMAIL PROTECTED] said:
> > Foolhardy as it may be, people do _use_ the operating system to run
> > important applications and an "application goes down or screws up" can be
> > quite serious.
>
> Yes. But "the kernel screws up
Linus Torvalds wrote:
>
> On Wed, 11 Oct 2000, Dag B wrote:
> >
[snip]
> > Expansion ROM at 1800 [disabled] [size=32M]
> > Capabilities: [dc] Power Management version 1
>
> There's something really wrong going on with your ethernet controller. It
> seems to try to take up
[EMAIL PROTECTED] said:
> On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote:
> > also moves forward a lot faster than glibc, and grows a lot. A bug in glibc
> > means an application goes down or screws up, a bug in the kernel can mean
> > masive data loss in no time at all.
>
On Wed, 11 Oct 2000, Nathan Paul Simons wrote:
> On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote:
> > Hardly. In fact the idea of distributing a different compiler for kernels
> > comes from debian and the kgcc naming convention from Conectiva.
>
> What different compiler? If
[EMAIL PROTECTED] said:
> The genuine Linux kernel distribution contains its own documentation
> on how to build and configure it.
Indeed it does. Documentation/Changes says:
GCC
---
You will need at least gcc 2.7.2 to compile the kernel. You currently
have several options for gcc-derived
> I don't think I understand your point. Are you saying that gcc cannot be
> expected to keep up with the ways in which the kernel uses it? My argument
> is that providing a compiler that actually regresses (old version compiles
> kernel, redhat 7.0 included one does not) is not a good choice.
> What different compiler? If you're talking about the kernel-package
> package of Debian, that's only scripts to generate a Debian kernel package
> from custom source.
The gcc272 package
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
[EMAIL PROTECTED] wrote:
> Maybe we should have the kernel print the CPU information it was
> compiled with before it does anything else. It'll make it easier to
> catch what may be a fairly common set of PEBCAK case
I was told that "printing" anything was out of the question, as the
[EMAIL PROTECTED] wrote:
Maybe we should have the kernel print the CPU information it was
compiled with before it does anything else. It'll make it easier to
catch what may be a fairly common set of PEBCAK case
I was told that "printing" anything was out of the question, as the
What different compiler? If you're talking about the kernel-package
package of Debian, that's only scripts to generate a Debian kernel package
from custom source.
The gcc272 package
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
I don't think I understand your point. Are you saying that gcc cannot be
expected to keep up with the ways in which the kernel uses it? My argument
is that providing a compiler that actually regresses (old version compiles
kernel, redhat 7.0 included one does not) is not a good choice.
The
On Wed, 11 Oct 2000, Nathan Paul Simons wrote:
On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote:
Hardly. In fact the idea of distributing a different compiler for kernels
comes from debian and the kgcc naming convention from Conectiva.
What different compiler? If you're
[EMAIL PROTECTED] said:
On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote:
also moves forward a lot faster than glibc, and grows a lot. A bug in glibc
means an application goes down or screws up, a bug in the kernel can mean
masive data loss in no time at all.
Foolhardy as
Linus Torvalds wrote:
On Wed, 11 Oct 2000, Dag B wrote:
[snip]
Expansion ROM at 1800 [disabled] [size=32M]
Capabilities: [dc] Power Management version 1
There's something really wrong going on with your ethernet controller. It
seems to try to take up all
On Thu, Oct 12, 2000 at 06:26:57AM -0400, Horst von Brand wrote:
[EMAIL PROTECTED] said:
Foolhardy as it may be, people do _use_ the operating system to run
important applications and an "application goes down or screws up" can be
quite serious.
Yes. But "the kernel screws up and
Cort Dougan [EMAIL PROTECTED] said:
Horst von Brand on Wed, Oct 11, 2000 at 11:21:06PM -0400 said:
[...]
} Oh, come on. The kernel (or glibc for that matter) is not about "inline
} asm()" at all! That is a tiny fraction of each. The kernel is different in
} that it has lots of
On Wed, 11 Oct 2000 18:10:40 -0400,
[EMAIL PROTECTED] wrote:
Are you sure it was compiled with the correct CPU? If you configure the
CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
refuse to boot.
Maybe we should have the kernel print the CPU information it was
On Thu, 12 Oct 2000, Keith Owens wrote:
If anything is going to detect the mismatch and complain, it has to be
the boot loader, after uncompressing and before entering the kernel
proper.
Perhaps we can add the processor type to linux_banner and print it from
setup.S.
--
"Love the
On Thu, 12 Oct 2000, Dag Bakke wrote:
Linus,
I realized there was one more test to do before deeming the hardware sane.
PCMCIA (16-bit) in my laptop is tested and works fine with three different
types of cards.
Another Xircom card behaved just the same (non-functional) in my latop.
My
On Thu, 12 Oct 2000 11:02:50 -0400,
"Chris Swiedler" [EMAIL PROTECTED] wrote:
But the kernel should be able to write directly to the screen, even if it's
extremely minimal information. Something like how LILO does it: test the
common hang-on-boot conditions (like wrong CPU type) and print a
PROTECTED], Martin Mares [EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED]
Subject: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource
collisions (fwd)
Ted,
Please add this to your list. Linux is unusable in these machines.
I have cc'ed Martin and Linus because they play
} Andrea Arcangeli <[EMAIL PROTECTED]> said:
} > On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
} > > I honestly see nothing wrong with it. There are different parts of
} > > the compiler stressed by the kernel build as opposed to most userland
} > > compilation, and
Date: Thu, 12 Oct 2000 04:18:23 +0200
From: Andrea Arcangeli <[EMAIL PROTECTED]>
I disagree the stability/feature ratio needs are different between
kernel and userspace (at least excluding the FPU handling that of
course doesn't matter for kernel :).
Tell that to people who want
On Wed, Oct 11, 2000 at 11:21:06PM -0400, Horst von Brand wrote:
> also moves forward a lot faster than glibc, and grows a lot. A bug in glibc
> means an application goes down or screws up, a bug in the kernel can mean
> masive data loss in no time at all.
Foolhardy as it may be, people do _use_
Andrea Arcangeli <[EMAIL PROTECTED]> said:
> On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
> > I honestly see nothing wrong with it. There are different parts of
> > the compiler stressed by the kernel build as opposed to most userland
> > compilation, and furthermore the
On Wed, Oct 11, 2000 at 06:19:23PM -0700, David S. Miller wrote:
> I honestly see nothing wrong with it. There are different parts of
> the compiler stressed by the kernel build as opposed to most userland
> compilation, and furthermore the desired compiler stability/feature
> ratio is different
}Date: Wed, 11 Oct 2000 19:36:15 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}I don't think "it's been done in UNIX before" is a
}strong argument for something being done now :)
}
} True, but I think that "different things have different requirements"
} is a strong argument.
On Wed, 11 Oct 2000, Nathan Paul Simons wrote:
> On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote:
> > Hardly. In fact the idea of distributing a different compiler for kernels
> > comes from debian and the kgcc naming convention from Conectiva.
>
> What different compiler? If
Date: Wed, 11 Oct 2000 19:36:15 -0600
From: Cort Dougan <[EMAIL PROTECTED]>
I don't think "it's been done in UNIX before" is a
strong argument for something being done now :)
True, but I think that "different things have different requirements"
is a strong argument. I merely
}Date: Wed, 11 Oct 2000 19:15:24 -0600
}From: Cort Dougan <[EMAIL PROTECTED]>
}
}It's not a new idea but that doesn't make it a good one. The idea
}of distributing the _same_ compiler but different versions is
}nutty.
}
} Actually, this is common practice even in the
Date:Wed, 11 Oct 2000 19:15:24 -0600
From: Cort Dougan <[EMAIL PROTECTED]>
It's not a new idea but that doesn't make it a good one. The idea
of distributing the _same_ compiler but different versions is
nutty.
Actually, this is common practice even in the commercial UNIX
> Hardly. In fact the idea of distributing a different compiler for kernels
> comes from debian and the kgcc naming convention from Conectiva.
It's not a new idea but that doesn't make it a good one. The idea of
distributing the _same_ compiler but different versions is nutty.
-
To unsubscribe
On Wed, Oct 11, 2000 at 10:55:17PM +0100, Alan Cox wrote:
> Hardly. In fact the idea of distributing a different compiler for kernels
> comes from debian and the kgcc naming convention from Conectiva.
What different compiler? If you're talking about the kernel-package
package of
On Thu, 12 Oct 2000 02:20:15 +0200,
Jan Niehusmann <[EMAIL PROTECTED]> wrote:
>> argued that critical routines should always be compiled with -i386,
>> unfortunately that includes all of printk and all console handling
>> (both serial and screen), not really an option.
>
>Neither printk nor
> argued that critical routines should always be compiled with -i386,
> unfortunately that includes all of printk and all console handling
> (both serial and screen), not really an option.
Neither printk nor console handling should be too performance
critical, and the performance of console i/o
On Wed, 11 Oct 2000 18:10:40 -0400,
[EMAIL PROTECTED] wrote:
>Are you sure it was compiled with the correct CPU? If you configure the
>CPU incorrectly (686 when you only have a 586, etc.) the kernel *will*
>refuse to boot.
>
>Maybe we should have the kernel print the CPU information it was
> The bug report said that it was verified under both SCSI and ATAPI MO,
> and that uses a different driver than the SCSI CD-ROM code, I think
ATAPI Magneto Optical is SCSI disk. The same thing applies to disk and CD,
it isnt just a CD-ROM path item. Both work in 2.2
-
To unsubscribe from
On Wed, Oct 11 2000, [EMAIL PROTECTED] wrote:
>Date: Mon, 9 Oct 2000 16:24:24 +0100 (BST)
>From: Alan Cox <[EMAIL PROTECTED]>
>
>> * FAT filesystem doesn't support 2kb sector sizes (did under 2.2.16,
>>doesn't under 2.4.0test7. Kazu Makashima, alan)
>
>[Same as
Date: Sun, 8 Oct 2000 23:24:49 -0700
From: Mitchell Blank Jr <[EMAIL PROTECTED]>
> * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
>more info)
I _highly_ suspect that this is not a 2.4 bug but is instead user error.
I've seen it several times.
1 - 100 of 193 matches
Mail list logo
