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
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 works for
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
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
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 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 in the base mtrr
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
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 people
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 fixed properly.
Hi Alan
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 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
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.
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.
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.
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,
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
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 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. Unless I
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 the
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,
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 if calling
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.
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 deleting.
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. Then
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 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
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 operator
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 .init
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
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
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
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
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
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 far as I
39 matches
Mail list logo
