(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
>
er bus but the first one, or
supporting real PCI IOs on all busses, but no legacy IOs. 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
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 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
7
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 se
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
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
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 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 yo
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 listen
"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
>do
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
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
> > *
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 thi
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 anarch
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 on
> > 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_B
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 fro
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 writi
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 be
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(), j
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 2000-23
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 tha
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? Tha
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, 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 dat
[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
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 lato
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 dolphin
> 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
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 hardware
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 an
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.
> Foolha
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 co
> 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 t
[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
"pr
} 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
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 a
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 desir
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 yo
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 pointed
}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 co
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 Debian,
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 conso
> 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
>comp
> 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 th
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 t
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.
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 the CDROM bug listed earlier I think]
The bug report said th
On Wed, 11 Oct 2000 09:56:46 -0400, Horst von Brand blurted forth:
> - RH 7 ships a gcc patched from CVS sources in order to take advantage of
>better (on ix86 mainly) optimizations on userland
> - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to
>be broken and
On Wed, 11 Oct 2000, Dag B wrote:
>
> > drivers/pcmcia/yenta.c to allocate more than 4MB of PCI memory window.
> [snip]
>
> > align = size = 32*1024*1024;
> Done.
> Didn't work. But it certainly made a difference.
>
> lspci -v now says:
>
> 06:00.0 Ethernet controller: Xircom Cardb
Date: Mon, 09 Oct 2000 20:13:35 +0200
From: Thomas Sailer <[EMAIL PROTECTED]>
Alan Cox wrote:
>
> > 4. Boot Time Failures
> >
> > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
> >more info)
>
> Add Palmax PD1100 hangs during boot s
> > On Red Hat 7.0, use "kgcc" for kernel compilation. This is
> > really an FAQ... Instead of changing distributions, try reading
> > manuals.
>
> What manuals ?
The ones on the CD that come with it
> The kgcc story looks to me like a lie from RedHat. In my opinion, they
> just don't want to
Linus Torvalds wrote:
>
> On Wed, 11 Oct 2000, Dag B wrote:
> > 2.4.0-test9/10p1
>
> Can you do another test with this (ie in-kernel pcmcia), AND enable
> debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in
[snip]
> drivers/pcmcia/yenta.c to allocate more than 4MB of PCI
On Wed, 11 Oct 2000 07:32:30 -0400, Jakub Jelinek blurted forth:
> The fact that we recommend using kgcc (especially for 2.2 kernels) does not
> mean that the default gcc is broken, but simply that using it for kernels
> has not been tested yet too much and there can be e.g. bugs in the way
>
On Wed, 11 Oct 2000, Mike A. Harris wrote:
> On 10 Oct 2000, Gnea wrote:
>
> >> Please add this to your list. Linux is unusable in these machines.
> >> I have cc'ed Martin and Linus because they play in that PCI area.
> >
> >erm, looking at your list it says that you're using Redhat 7.0, whi
Date: Tue, 10 Oct 2000 17:53:57 -0300 (BRST)
From: Rik van Riel <[EMAIL PROTECTED]>
> 2. Capable Of Corrupting Your FS/data
>
> * Non-atomic page-map operations can cause loss of dirty bit on
>pages (sct, alan)
Is anybody looking into fixing this bug ?
Accordi
On Wed, 11 Oct 2000, Dag B wrote:
>
> Tested with:
> 2.2.18pre15 + pcmcia-cs 3.1.21
> 2.4.0-test9/10p1
Can you do another test with this (ie in-kernel pcmcia), AND enable
debugging in both drivers/pci/pci.c and in arch/i386/kernel/pci-i386.h (in
both cases, just change the #undef DEBUG to a #d
Keywords: cardbus, dell, xircom, pci, resources
In short:
Xircom Realport cardbus cards still do not work under Linux in (my) Dell
Latitude CPi laptop. A problem indication shows up even before loading
the xircom driver. This is not the Latitude docking-station problem,
which has been
noted by ot
> - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to
> be broken and not compilable with new gcc's
> - No, the kernel won't be fixed. The work is huge, and the risk is much too
> high
Actually I take the same attitude I took with 2.95. If you submit patches which
fix
Gnea <[EMAIL PROTECTED]> said:
> On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:
[...]
> erm, looking at your list it says that you're using Redhat 7.0, which
> is known to ship with a buggy gcc, which is KNOWN to do nasty things
> with kernels.
OK, let's set a few things strai
On Wed, 11 Oct 2000, Alan Cox wrote:
> The only case that 2.95 was at fault is strstr() miscompiles which 2.96
> snapshots actually got right.
I couldn't get llabs() to compile correctly either on 2.95.2. There were other
small problems when using long long, but I can't remember them right now.
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote:
>
> On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:
>
> >
> > Ted,
> >
> > Please add this to your list. Linux is unusable in these machines.
> > I have cc'ed Martin and Linus because they play in that PCI area.
>
> erm,
> erm, looking at your list it says that you're using Redhat 7.0, which
> is known to ship with a buggy gcc, which is KNOWN to do nasty things
> with kernels.
Its not a buggy gcc. Well its a less buggy gcc than 2.95 or egcs 1.1.2
The problem is the *kernel* side of things. The compiler folks k
On 10 Oct 2000, Gnea wrote:
>> Please add this to your list. Linux is unusable in these machines.
>> I have cc'ed Martin and Linus because they play in that PCI area.
>
>erm, looking at your list it says that you're using Redhat 7.0, which
>is known to ship with a buggy gcc, which is KNOWN to d
On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth:
>
> Ted,
>
> Please add this to your list. Linux is unusable in these machines.
> I have cc'ed Martin and Linus because they play in that PCI area.
erm, looking at your list it says that you're using Redhat 7.0, which
is known
Ted,
Please add this to your list. Linux is unusable in these machines.
I have cc'ed Martin and Linus because they play in that PCI area.
cheers,
jamal
-- Forwarded message --
Date: Thu, 5 Oct 2000 17:23:13 -0400 (EDT)
From: jamal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subje
> It is not a configuration that I currently test. I am told it mostly
> works, though some client drivers are not SMP safe. It is something
> that should be fixed eventually, for sure, but given the number of
> open issues with PCMCIA in 2.4, I don't think it is high on the list.
> If you want
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> 2. Capable Of Corrupting Your FS/data
>
> * Non-atomic page-map operations can cause loss of dirty bit on
>pages (sct, alan)
Is anybody looking into fixing this bug ?
> 9. To Do
>
> * mm->rss is modified in some places without ho
On Tue, Oct 10, 2000 at 02:08:45PM -0400, [EMAIL PROTECTED] wrote:
>
> I am one of those people that uses PCMCIA on an SMP machine, I also
> use 2.4. Aside from the very occasional problem, I don't see any
> locking issues. Is it possible to just leave it as is with a warning?
I think the confi
> > So I propose that this item be removed simply by stating "Linux 2.4 does
> > not support PCMCIA on multiprocessors". Comments, David?
>
> There are some people who use PCMCIA on SMP desktop boxes; many
> wireless network cards are only made as PCMCIA cards, and the "desktop
> version" consi
On Wed, Oct 11, 2000 at 12:04:22AM +1100, Andrew Morton wrote:
> > * Misc locking problems
> > + drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are
> > missing, on UP the sleep_on() use is unsafe.
>
> It is my understanding that hen's teeth easily outnumber SMP PCM
[EMAIL PROTECTED] wrote:
>
> 3. Security
>
> * Fix module remove race bug (still to be done: TTY, ldisc, I2C,
>video_device - Al Viro) (Rogier Wolff will handle ATM)
Patch for tty and ldisc is in your inbox...
> ...
>
> 8. Fix Exists But Isnt Merged
>
> ...
> * Many network
Mitchell Blank Jr writes:
> [EMAIL PROTECTED] wrote:
> > 4. Boot Time Failures
> [...]
> > * 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.
Y
On Mon, Oct 09, 2000 at 04:17:01PM -0700, Dunlap, Randy wrote:
> . OOPS in usb-storage from the error-recovery handler. {CRITICAL}
> (Matthew Dharm; [EMAIL PROTECTED])
This is fixed as of test9.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB
Hi Ted,
Here's an updated USB 2.4 TODO list.
The new entries (changes) are marked with '+'.
~Randy
USB Status/Problems in 2.4.0-test9
2000-October-09
1. Should [already] Be Fixed
. hid joystick handling (patch from Vojtech) (2.4.0.9.4)
Ted,
Here are some corrections to the published list.
I'm working on new additions now.
~Randy
> 6. In Progress
>
> * USB: hotplug (PNP) and module autoloader support
+ Move to "1. Should Be Fixed". We want more testing of it, of course.
> 9. To Do
>
> * USB: OHCI root-hub-timer
Alan Cox wrote:
>
> > 4. Boot Time Failures
> >
> > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
> >more info)
>
> Add Palmax PD1100 hangs during boot since 2.4.0-test9
My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the
kernel..."
and before pri
> * RTL 8139 cards sometimes stop responding. Both drivers don't
>handle this quite good enough yet. (reported by Rogier Wolff,
>tentatively reported as fixed by David Ford.)
2.4.0-test9 Spontaneous reboots under network load with this
driver. Sorry, no more
On Mon, Oct 09, 2000 at 12:19:26AM -0400, [EMAIL PROTECTED] wrote:
>
> Linux 2.4 Status/TODO Page
>
>* 2.4.0-test2 breaks the behaviour of the ether=0,0,eth1 boot
> parameter (dwguest)
This has been fixed.
-
To unsubscribe from this list: send the line "unsubsc
> 4. Boot Time Failures
>
> * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
>more info)
Add Palmax PD1100 hangs during boot since 2.4.0-test9
> 6. In Progress
> * Finish I2O merge (Intel/Alan)
Assume this is done for 2.4.0. There are things to look at but i
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> * Writing to tapes > 2.4G causes tar to fail with EIO (using
>2.4.0-test7-pre5; it works under 2.4.0-test1-ac18 --- Tigran
>Aivazian)
this has now been working since test8 and certainly in test9. Why it
failed on test7-pre5? Proba
[EMAIL PROTECTED] wrote:
>
> 8. Fix Exists But Isnt Merged
> * 2.4.0-test8 has a BUG at ll_rw_blk:711. (Johnny Accot, Steffen
>Luitz) (Al Viro has a patch)
Said patch has already been merged in the test9-pre and -final series
and the bug can be considered fixed.
-Udo.
-
To unsubsc
[EMAIL PROTECTED] wrote:
> 4. Boot Time Failures
[...]
> * 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.
On all kernel versions prior to 2.3.11 if you
On Sun, 8 Oct 2000, David Ford wrote:
> > > Linux 2.4 Status/TODO Page
> > > * RTL 8139 cards sometimes stop responding.
> > (2.2.18pre) Both drivers oops a lot for me, so there seems to be a more
> > serious problem here.
> This is the 2.4 status/todo page, see t
1 - 100 of 103 matches
Mail list logo
