On Mer, 2005-03-09 at 20:36, Alan Cox wrote:
> On Mer, 2005-03-09 at 19:09, Andries Brouwer wrote:
> > The moment you report that the follow-up patch is fine, we can
> > remove the #if 0 and insert the initcalls instead.
> >
> > So, all is well today, and we are waiting for your report.
>
> Ok wo
On Mer, 2005-03-09 at 19:09, Andries Brouwer wrote:
> The moment you report that the follow-up patch is fine, we can
> remove the #if 0 and insert the initcalls instead.
>
> So, all is well today, and we are waiting for your report.
Ok works for me. I'll let you know ASAP.
-
To unsubscribe from
On Wed, Mar 09, 2005 at 04:55:27PM +, Alan Cox wrote:
> > [PATCH] remove dead cyrix/centaur mtrr init code
>
> This patch was discussed previously and declared incorrect. The ->init
> method call is missing in the base mtrr code.
>
> Should be reverted and/or
On Mer, 2005-03-09 at 17:09, Linus Torvalds wrote:
> On Wed, 9 Mar 2005, Alan Cox wrote:
> >
> > This patch was discussed previously and declared incorrect.
>
> Well, it was also declared as a "don't care" by Dave, I think, by virtue
> of nobody having ever complained.
And in further discussion
On Wed, 9 Mar 2005, Alan Cox wrote:
>
> This patch was discussed previously and declared incorrect.
Well, it was also declared as a "don't care" by Dave, I think, by virtue
of nobody having ever complained.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linu
On Maw, 2005-03-08 at 17:40, Linux Kernel Mailing List wrote:
> ChangeSet 1.2094, 2005/03/08 09:40:59-08:00, [EMAIL PROTECTED]
>
> [PATCH] remove dead cyrix/centaur mtrr init code
This patch was discussed previously and declared incorrect. The ->init
method call is missing
On Mer, 2005-03-02 at 22:28, Dave Jones wrote:
> The winchips had a funky feature where you could mark system ram
> writes as out-of-order. This led to something like a 25% speedup iirc
> on benchmarks that did lots of memory copying. lmbench showed
> significant wins iirc, but any results I had sa
On Wed, Mar 02, 2005 at 01:45:43PM +, Alan Cox wrote:
> On Mer, 2005-03-02 at 08:02, Dave Jones wrote:
> > If there are any of them still being used out there, I'd be even
> > more surprised if they're running 2.6. Then again, there are
> > probably loonies out there running it on 386/486's. 8
On Wed, Mar 02, 2005 at 11:21:06PM +0100, Andries Brouwer wrote:
> On Wed, Mar 02, 2005 at 01:45:43PM +, Alan Cox wrote:
> > On Mer, 2005-03-02 at 08:02, Dave Jones wrote:
> > > If there are any of them still being used out there, I'd be even
> > > more surprised if they're running 2.6. Th
Dave Jones wrote:
On Wed, Mar 02, 2005 at 03:59:00PM +0100, Ondrej Zary wrote:
> >>The failure to invoke the ->init operator appears to be the bug.
> >>The centaur code definitely wants the mcr init function to be called.
> >
> >Yes, I expected that to be the answer. Therefore #if 0 instead of
On 2005.03.02 08:02, Dave Jones wrote:
The Winchips never really sold that well, and stopped being produced
when IDT sold off Centaur. It was a niche processor in 1997. In 2005,
I'll be surprised if there are that many of them still working.
Mine lost its magic smoke for no reason around ~2002.
If
On Wed, Mar 02, 2005 at 03:59:00PM +0100, Ondrej Zary wrote:
> >>The failure to invoke the ->init operator appears to be the bug.
> >>The centaur code definitely wants the mcr init function to be called.
> >
> >Yes, I expected that to be the answer. Therefore #if 0 instead of deleting.
> >But
Andries Brouwer wrote:
On Tue, Mar 01, 2005 at 11:52:44PM +, Alan Cox wrote:
On Llu, 2005-02-28 at 19:20, Andries Brouwer wrote:
One such case is the mtrr code, where struct mtrr_ops has an
init field pointing at __init functions. Unless I overlook
something, this case may be easy to settle, si
On Mer, 2005-03-02 at 08:02, Dave Jones wrote:
> If there are any of them still being used out there, I'd be even
> more surprised if they're running 2.6. Then again, there are
> probably loonies out there running it on 386/486's. 8-)
I have one here running 2.4 still. I can test a 2.6 fix for th
On Wed, Mar 02, 2005 at 08:50:38AM +0100, Andries Brouwer wrote:
> On Tue, Mar 01, 2005 at 11:52:44PM +, Alan Cox wrote:
> > On Llu, 2005-02-28 at 19:20, Andries Brouwer wrote:
> > > One such case is the mtrr code, where struct mtrr_ops has an
> > > init field pointing at __init functions.
On Tue, Mar 01, 2005 at 11:52:44PM +, Alan Cox wrote:
> On Llu, 2005-02-28 at 19:20, Andries Brouwer wrote:
> > One such case is the mtrr code, where struct mtrr_ops has an
> > init field pointing at __init functions. Unless I overlook
> > something, this case may be easy to settle, since the .
On Llu, 2005-02-28 at 19:20, Andries Brouwer wrote:
> One such case is the mtrr code, where struct mtrr_ops has an
> init field pointing at __init functions. Unless I overlook
> something, this case may be easy to settle, since the .init
> field is never used.
The failure to invoke the ->init oper
On Mon, Feb 28, 2005 at 08:35:29PM +0100, Adrian Bunk wrote:
> Hi Andries,
>
> your patch has many overlappings with a patch of mine aleady in -mm
> (both none of the two patches is a subset of the other one).
>
> Nowadays, working against -mm often avoids duplicate work.
>
> cu
> Adrian
As fa
Hi Andries,
your patch has many overlappings with a patch of mine aleady in -mm
(both none of the two patches is a subset of the other one).
Nowadays, working against -mm often avoids duplicate work.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of t
There are several cases where __init function pointers are
stored in a general purpose struct. For example, a SCSI
template may contain a __init detect function.
Have not yet thought of an elegant way to avoid this.
One such case is the mtrr code, where struct mtrr_ops has an
init field pointing a
20 matches
Mail list logo
