Hi,
Quoting Konrad Rzeszutek Wilk, who wrote the following on Mon, 28 Oct 2013:
On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Mail is big, I think I got your essential points but I didn
> On Oct 23, 2013, at 12:05 AM, Daniel Kiper wrote:
>
>> On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder'
>> Serbinenko wrote:
>>> On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Mail is big, I think I got your essential points but I didn't read it whol
Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following on...:
On 21.10.2013 22:53, Seth Goldberg wrote:
Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
Hi,
During work on multiboot2 protocol support for Xen it was discovered
that memory map
Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
Hi,
During work on multiboot2 protocol support for Xen it was discovered
that memory map passed via relevant tag could not represent wide range
of memory types available on EFI platforms. Additionally, GRUB2
implementation cal
Hi,
I noticed discussion of the various Via KT133A chipset problems related
to
Athlon optimized kernels has trailed off. Are people successfully using
the patch that Alan Cox posted, or are there still problems?
I just ran into this last night (I thought all the Athlon chipset bugs
had
been
>
> As all this is trying to avoid bus turnarounds (i.e. switching from
> reading to writing), wouldn't it be fastest to just trust that the CPU
> has at least 4k worth of cache? (and hope for the best that we don't
> get interrupted in the meanwhile).
>
> void copy_page (char *dest, char *sourc
Hi,
Before I go any further with this investigation, I'd like to get an
idea
of how much of a performance improvement the K7 fast_page_copy will give
me.
Can someone suggest the best benchmark to test the speed of this
routine?
Thanks,
Seth
-
To unsubscribe from this list: send the line "un
Chris Wedgwood wrote:
>
> On Fri, May 04, 2001 at 05:26:57PM -0700, Joseph Carter wrote:
>
> I don't see how they figure, but in case there was any doubt I
> have a VIA KT133A/686B board (Abit KT7A) and don't experience
> anything resembling disk corruption unless the box crashes for
Gordon Sadler wrote:
>
> On Fri, May 04, 2001 at 01:28:23AM -0700, Seth Goldberg wrote:Seth Goldberg
><[EMAIL PROTECTED]>
> > Gordon Sadler wrote:
> > >
> > > On Fri, May 04, 2001 at 12:43:22AM -0700, Seth Goldberg wrote:
> > > > Hi,
> &g
On Fri, 4 May 2001, Manfred Spraul wrote:
| > ---
| > > __asm__ __volatile__ (
| > 158c157
| > < "3: movw $0x1AEB, 1b\n"
| > ---
| > > "3: movw $0x1AEB, 1b\n" /* jmp on 26 bytes */
| > 166c165
| > < */
| > ---
| > >
| > 170c169
| > < "1: nop\n" /*
Hi,
After removing my head from my a**, I revised the code that checks
the memory copy in the fast_page_copy routine. The machine then
proceeded
not to stop at my panic, but I got my "normal" oopses. I then had an
idea and removed all the prefetch instructions from the beginning of the
routin
Doh. I feel like a moron. Thanks.. will do...
--S
Brian Gerst wrote:
>
> Seth Goldberg wrote:
> >
> > Hi,
> >
> > I implemented a small check loop at the end of the fast_page_copy
> > routine in mmx.c for the Athlon. Booting the resulting kernel
>
Hi,
I implemented a small check loop at the end of the fast_page_copy
routine in mmx.c for the Athlon. Booting the resulting kernel
yields an interesting result. Every single time, the kernel
panics RIGHT AFTER it frees unused kernel memory from bootup.
I encourage those of you with the same p
Hi,
Do you think it would be a good idea to check the fast_copy
athlon mmx routine by putting in code that basically compares
the source & destination copies and checks if they are equal?
I realize that will slow down the system, but for testing,
it seems like a good idea...
--S
-
To unsubsc
Gordon Sadler wrote:
>
> On Fri, May 04, 2001 at 12:43:22AM -0700, Seth Goldberg wrote:
> > Hi,
Hi,
Have you tried compiling ther kernel with Athlon optimiztions turned
off (try
compiling for a K6-II[I])? The has stopped the same thing from
happening on
my system and those of
Hi,
What hardware are you running?
--seth
>
> Please CC any replies.
> Please refer to my previous post 'PROBLEM: 2.4.4 oops, will not boot'
> for complete machine details/configuration.
>
> I'm still working on different 2.4 kernels trying to get just one to
> boot normally. Currently
Jonathan Morton wrote:
>
> I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C
> in a warm room) is giving me no trouble. This is with the board and RAM
> pushed as fast as it will go without actually overclocking anything... and
> yes, I do have Athlon/K7 optimisations
Thanks moses -- this is the instability that I have as well.
I tried compiling on 1/2 of the k7 optimized mmx routines.
So far, running with JUST the fast_clear_page using k7 streaming (and
not
fast_copy_page), the system is still stable. I'll try adding fast_copy
_page, but I think that's whe
Hi Tom,
Nope. No emulation here. Thanks for trying tho ;).
--Seth
Tom Leete wrote:
>
> Seth Goldberg wrote:
> >
> > Hi,
> >
> > So it seems that CONFIG_X86_USE_3DNOW is simply used to
> > enable access to the routines in mmx.c (the athlon-optimized
&g
Manfred Spraul wrote:
>
> > So it seems that CONFIG_X86_USE_3DNOW is simply used to
> > enable access to the routines in mmx.c (the athlon-optimized
> > routines on CONFIG_K7 kernels), so then it appears that somehow
> > this is corrupting memory / not behaving as it should (very
> > technical, r
Mark Hahn wrote:
>
> > And that's exactly what I did :)... I found that ONLY the combination
> > of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in
> > results in this wackiness. I should alos repeat that I *DO* see that
>
> I doubt that USE_3DNOW is causing the problem, but
Hi :)
And that's exactly what I did :)... I found that ONLY the combination
of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in
mmx.c)
results in this wackiness. I should alos repeat that I *DO* see that
wierdness you described with 3DNOW (in my case, it was that kde locks
up
Dan Hollis wrote:
>
> On Tue, 1 May 2001, Seth Goldberg wrote:
> > I Should clarify that this is the KX133A chipset.
>
> No such thing. Surely you mean KT133A. No X.
>
Surely :)... That's what sleep deprivation does to you ;).
--S
-
To unsubscribe fro
Wow. My very first pseudo-flame. Thank you for making me feel welcome
;).
--S
Jesper Juhl wrote:
>
> Seth Goldberg wrote:
>
> > Test.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a mess
Will Newton wrote:
I Should clarify that this is the KX133A chipset. In any event,
there are a bunch of people having this problem (check out the list
archives). I just upgraded to this IWILL board from an Abit KA7-RAID
(which worked with no problem), so I'm just trying tofgure it out :)
-S
Hi,
So it seems that CONFIG_X86_USE_3DNOW is simply used to
enable access to the routines in mmx.c (the athlon-optimized
routines on CONFIG_K7 kernels), so then it appears that somehow
this is corrupting memory / not behaving as it should (very
technical, right?) :)...
--Seth
-
To unsubscribe
Test.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ok, so the subject is an attention-getter :).
Peep this, homies:
Hi,
I've been doing some research, trying to figure out why the VIA/Athlon
is exhibiting weird behavior under K7 optimizations. The jist of my
research is that compiling a kernel for ANY CPU with the Athlon MMX
optimization
*A
28 matches
Mail list logo
