(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
>
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
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
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
> 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
Simon Richter wrote:
> On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > Linux 2.4 Status/TODO Page
>
> > * RTL 8139 cards sometimes stop responding. Both drivers don't
> >handle this quite good enough yet. (reported by Rogier Wolff,
> >tentatively re
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> Linux 2.4 Status/TODO Page
> * 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.)
(
92 matches
Mail list logo
