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
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
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
> > 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
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 very
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. The other way
Trace; 037f END_OF_CODE+3fcfb2ab/
Trace; END_OF_CODE+3fcfaf2c/
Trace; END_OF_CODE+3fcfaf2c/
Trace; 0720 END_OF_CODE+3fcfb64c/
Lets ignore the crap above..
Trace; c01b956a ide_build_dmatable+2a/120
Trace; c01b3fb5 ide_set_handler+55/60
Trace;
Alan Cox wrote:
Trace; c01b956a ide_build_dmatable+2a/120
Trace; c01b3fb5 ide_set_handler+55/60
Trace; c01b9aca ide_dmaproc+11a/210
Trace; c01b9380 ide_dma_intr+0/b0
Trace; c01b9940 dma_timer_expiry+0/70
Trace; c01bd457 do_rw_disk+257/300
Trace; c01b4d2a ide_wait_stat+7a/e0
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 fixes...
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
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
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]
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 kernel. I now
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.
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
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
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.
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
> > 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
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
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 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 unsubscribe
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 saving of
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
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
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
> 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
>
> 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
> 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"
> 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
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
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
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
routine
---
__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)\n
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 /* prefetch 320(%0)\n */
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 instructions from
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.
What
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 areas?
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 issues
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.
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.
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
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 do
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
50 matches
Mail list logo
