Re: Compile errors: RCPCI, LANE, and others

2001-01-02 Thread Panu Matilainen
On Tue, 2 Jan 2001, J Sloan wrote: > Alan Cox wrote: > > > Bzzt, wrong. Red Hat 7 compiles the 2.4 tree beautifully with gcc 2.96 as well. > > Please grow up. > > Yes indeed - on my quad CPU Red Hat 7 server, I accidentally > forgot to say CC=kgcc during the last kernel build, and ended > up with

Re: Compile errors: RCPCI, LANE, and others

2001-01-02 Thread Panu Matilainen
On Tue, 2 Jan 2001, J Sloan wrote: Alan Cox wrote: Bzzt, wrong. Red Hat 7 compiles the 2.4 tree beautifully with gcc 2.96 as well. Please grow up. Yes indeed - on my quad CPU Red Hat 7 server, I accidentally forgot to say CC=kgcc during the last kernel build, and ended up with a

Re: test12-pre5

2000-12-06 Thread Panu Matilainen
On Mon, 4 Dec 2000, Linus Torvalds wrote: > > Ok, this contains one of the fixes for the dirty inode buffer list (the > other fix is pending, simply because I still want to understand why it > would be needed at all). Al? > > Also, it has the final installment of the PageDirty handling, and now

Re: test12-pre5

2000-12-06 Thread Panu Matilainen
On Mon, 4 Dec 2000, Linus Torvalds wrote: Ok, this contains one of the fixes for the dirty inode buffer list (the other fix is pending, simply because I still want to understand why it would be needed at all). Al? Also, it has the final installment of the PageDirty handling, and now

Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-15 Thread Panu Matilainen
On Thu, 12 Oct 2000, Keith Owens wrote: > On Thu, 12 Oct 2000 12:56:09 +0100 (BST), > Tigran Aivazian <[EMAIL PROTECTED]> wrote: > >one correction -- it was "down and up the interface" that did the trick > >and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better > >formulated

Re: test10-pre1 problems on 4-way SuperServer8050

2000-10-15 Thread Panu Matilainen
On Thu, 12 Oct 2000, Keith Owens wrote: On Thu, 12 Oct 2000 12:56:09 +0100 (BST), Tigran Aivazian [EMAIL PROTECTED] wrote: one correction -- it was "down and up the interface" that did the trick and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better formulated as "when