Am Samstag, 5. Mai 2001 09:13 schrieben Sie:
> > My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167
> > (AMD Irongate C4) with your 2.4.4-ac5, now :-(
>
> Manfred has a good explanation for that. Im hoping it also explains the
> VIA problem too
>
> > I am open for any test f
Alan Cox wrote:
>
> > Trace; c01b956a
> > Trace; c01b3fb5
> > Trace; c01b9aca
> > Trace; c01b9380
> > Trace; c01b9940
> > Trace; c01bd457
> > Trace; c01b4d2a
> > Trace; c01b5010
> > Trace; c01b51ff
>
> We seem to be several layers into recursive use of the ide driver - which
> shouldnt
> Trace; 037f
> Trace;
> Trace;
> Trace; 0720
Lets ignore the crap above..
> Trace; c01b956a
> Trace; c01b3fb5
> Trace; c01b9aca
> Trace; c01b9380
> Trace; c01b9940
> Trace; c01bd457
> Trace; c01b4d2a
> Trace; c01b5010
> Trace; c01b51ff
We seem to be sever
Alan Cox wrote:
>
>
> > IIRC this thread is about boot going catatonic right after unloading
> > __initmem.
>
> Nope. Its about memory corruptions. Your bug sounds very different
>
> > Earlier, it looks like handle_mm_fault is being triggered from
> > fast_clear_page.
>
> That would be messy.
> > What still stands out is that exactly _zero_ people have reported the same
> > problem with non VIA chipset Athlons.
>
> Not any more :-(
Still the same
> IIRC this thread is about boot going catatonic right after unloading
> __initmem.
Nope. Its about memory corruptions. Your bug sounds v
Alan Cox wrote:
>
> > 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
>
> Ok
>
> > idea and removed all the prefetch instructions from the beginning of the
> > routine and tried the resultin
In article <[EMAIL PROTECTED]> you wrote:
> Arjan - care to unroll the tail 320 bytes of copying from the main loop ?
I'll see what I can do to make us not loose too much speed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Have non-production via KT133a, will test :) (tyan mobo, 1.33ghz, tulip eth, an
idea drive, nothing really exciting, just a fast ath)
-j
John R Lenton enlightened recipients with the following on 06May2001:
> On Sat, May 05, 2001 at 08:20:56AM +0100, Alan Cox wrote:
> > Dont panic just yet. Manf
On Sat, May 05, 2001 at 08:20:56AM +0100, Alan Cox wrote:
> Dont panic just yet. Manfred's observation could mean we hit chipset specific
> behaviour on prefetches.
OK - Please let me know when to start.
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
BOFH excuse #349:
Stray Alpha Part
Quick note. I *AM* seeing this problem on a Tyan S2390B which has the
Via KT133A chipset on it.
AMD Athlon 1.33ghz
2x256m DIMMs
Linux 2.4.4-ac5
I haven't done the ksymoops conversions yet, but please let me know if you'd
like anything else. But basically, it looks exactly like what all the IWI
> > one of them to a new mb with a non-VIA chipset (Asus A7A266), and it boot=
> ed the
> > first Athlon kernel I tried (2.4.4). No other changes to .config, same
> > processor as before, same memory, same disks, same video, same case, same=
> power
> > cord, you name it.
>
> damn. I guess the
> My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 (AMD
> Irongate C4) with your 2.4.4-ac5, now :-(
Manfred has a good explanation for that. Im hoping it also explains the
VIA problem too
> I am open for any test fixes...
Watch this space -> <- ;)
Alan
-
To unsubscri
On Sat, May 05, 2001 at 12:10:06AM +0600, Bobby D. Bryant wrote:
> They do boot PIII kernels reliably for all those variants, though they still
> suffer occasional oopses, hangs, or crashes (as discussed in other threads).
and as happens with my SMP pIII VIA-based boxed (and I've finally
fixed th
Aaron Tiensivu wrote:
> > What still stands out is that exactly _zero_ people have reported the same
> > problem with non VIA chipset Athlons.
>
> This might be grasping at straws [...] This could be (total conjecture)
> related somehow to the corruption bugs they are admitting to in
> the 686B
On Sat, May 05, 2001 at 03:51:13PM +1200, Chris Wedgwood 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
> some other reason. I
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
> What still stands out is that exactly _zero_ people have reported the same
> problem with non VIA chipset Athlons.
Sorry Alan, but...
My (very) old Athlon 550 (model 1, stepping 2) show it on my MSI MS-6167 (AMD
Irongate C4) with your 2.4.4-ac5, now :-(
Even with or without apm/acpi enabled.
On Fri, May 04, 2001 at 06:26:14PM -0400, Aaron Tiensivu wrote:
> This might be grasping at straws I remember VIA problem in the "good old
> days" of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write
> settings that would cause issues like we're seeing with the Athlon
> pre-fetches
> What still stands out is that exactly _zero_ people have reported the same
> problem with non VIA chipset Athlons.
This might be grasping at straws I remember VIA problem in the "good old
days" of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write
settings that would cause issue
> prefetch 320(%0) can fetch memory behind the end of the source page.
> Perhaps it accesses memory in the ISA hole, or beyond the end of memory?
> Could you post the e820 map from dmesg?
>
> It's possible to build manually a memory map.
> Could you build one with wide margins from "dangerous" ar
> 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
Ok
> idea and removed all the prefetch instructions from the beginning of the
> routine and tried the resultin kernel. I now have no crashes.
>
Seth Goldberg wrote:
>
> 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 instruct
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" /*
> ---
> > __asm__ __volatile__ (
> 158c157
> < "3: movw $0x1AEB, 1b\n"
> ---
> > "3: movw $0x1AEB, 1b\n" /* jmp on 26 bytes */
> 166c165
> < */
> ---
> >
> 170c169
> < "1: nop\n" /* prefetch 320(%0)\n" */
> ---
> > "1: prefetch 320(%0)\
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
25 matches
Mail list logo
