Mailing List Archive

On 6/25/05, Paul Heinlein <heinlein@madboa.com> wrote:
> On Sat, 25 Jun 2005, David S. Miller wrote:
>
> > I think I can fix this bug if people give me some information about
> > the characteristics of the system afflicted by the problem.
> > Answering a few questions will go a long way:
>
> 2.6.9 and .10 both failed on my Blade 100, which is all stock (OBP
> 4.0.45, UltraSparc IIe, IDE) except for an additional 256M of memory.
>
> The failures were hard to predict. I seem to recall at one point I had
> an uptime of nearly a month, but usually the crashes recur every week
> or so. Sometimes the crash would happen during nightly backups, but on
> at least one occasion it crashed during a period of zero load average
> in the middle of the day.
>
> Under 2.4.x, the thing just runs...

I had two Blade 100s that were also almost stock, the only difference
between mine and yours is the pair of 120GB drives I was using instead
of the stock 10GB and the CD-ROM. 2.6.5 worked perfectly, later
versions had random lock-ups as you mentioned. Give 2.6.5 a try, it
works great.

From the one box I have left (currently doing a lot of nothing):
2.6.5 #1 Mon Jul 26 18:37:05 PDT 2004 sparc64 sun4u TI UltraSparc IIe
(Hummingbird)
14:43:12 up 251 days, 23:39, 2 users, load average: 0.00, 0.03, 0.04


> -- Paul Heinlein <heinlein@madboa.com>

Mike

--
gentoo-sparc@gentoo.org mailing list

On Mon, 2005-06-27 at 17:16 +0000, Ferris McCormick wrote:
> On Mon, 2005-06-27 at 00:33 -0400, David S. Miller wrote:
> > [. CC:'ing Josh Grebe, he could reproduce these SMP hangs on
> > his box quite reliably ]
> >
>
> I'm not squash, but I have an update. System=U60(2x450), 2 disks
> installed.
>
> Kernel=2.6.12_rc6
>
> Patch installs without any issues; however, system up time was about
> 4 hours; died under heavy disk activity (trying to do reverse dependency
> check for package rebuilds). The failure looked like it always looks:
> everything stops, system responds only to the reset switch.
>

OK, here's a better update. Kernel is from gentoo-sources, sync'ed to
2.6.12.1. Patch installs without incident. And, status:

U2(2x400) --- comes up fine, not running long enough for status.
However 2.6.12 generally has done pretty well on this system.

U60(2x450) --- Does much better than other 2.6.xx kernels have, but
squash's crashme.sh script does crash it. (Hard failure on pass 3;
system was NOT otherwise idle, and before the crash I had done a
'umount -a -t nfs' to unmount one file system completely independent of
the crashme playgrounds.) For this test, crashme is 'cp -R'-ing from a
file system on /dev/sdb4 --> /dev/sda6.

SB1000(2x900) --- With patch, under heavy load up time is measured in
minutes (as under 10 minutes) consistently. Same kernel, but without
patch, system seems stable.

Hope this helps, although it's not what anyone wanted to hear. We're
all awaiting squash's netra results for the *real truth*.

{For those who don't know: crashme is a do-forever shell script which:
cp -R <directory-with-lots-of-files> <someplace>; tar cf someplace.tar
someplace; rm -rf someplace; tar xf someplace.tar; rm -rf someplace
someplace.tar}

Regards,
Ferris

--
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave and All,

I'm sorry to say that I still crash reliably with this patch. Just to recap, it
is a netra 1405, 4x440, 1G ram. Crashed after about 30 minutes of running my
disk-loading crashme.sh.

Josh



David S. Miller wrote:
> [. CC:'ing Josh Grebe, he could reproduce these SMP hangs on
> his box quite reliably ]
>
> Ok folks, give this patch a try. It applies cleanly to
> 2.6.12 and 2.6.12.1
>
> [SPARC64]: Avoid membar instructions in delay slots.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwtujFAhB33r2ACYRAoHNAJ45m29VFshxxLulusq+WFABtM8T/gCfQ+t9
PbTBBnflmnFpeo4/PCYvBaM=
=wYRV
-----END PGP SIGNATURE-----
--
gentoo-sparc@gentoo.org mailing list

Ferris McCormick writes:
> U2(2x400) --- comes up fine, not running long enough for status.
> However 2.6.12 generally has done pretty well on this system.
> [...]
> {For those who don't know: crashme is a do-forever shell
> script which:
> cp -R <directory-with-lots-of-files> <someplace>; tar cf
> someplace.tar someplace; rm -rf someplace; tar xf
> someplace.tar; rm -rf someplace someplace.tar}


Been running 'crashme' for the past hour on my Ultra Enterprise 2
(2x300) 2.6.12.1+dm

Takes about 11 minutes per loop. No issues so far.
I've even started up X (to clear up the screen garbage that
happens when the console-blanker kicks in) while it was
running without issue.

This is currently running between sda and sdb.

if it's stable here, the next test is to plug in the external array
and test between internal and external, then pure external.
--
gentoo-sparc@gentoo.org mailing list

Turns out I responded to myself, when I wrote at 10:39am:
> Been running 'crashme' for the past hour on my Ultra Enterprise 2
> (2x300) 2.6.12.1+dm
>
> Takes about 11 minutes per loop. No issues so far.
> I've even started up X (to clear up the screen garbage that
> happens when the console-blanker kicks in) while it was
> running without issue.
>
> This is currently running between sda and sdb.
>
> if it's stable here, the next test is to plug in the external
> array and test between internal and external, then pure external.

And it crashed at approximately 12:20pm, for a total runtime of
about 2 hours 40 minutes.

guess I don't need to worry about the external drives just yet.

--
gentoo-sparc@gentoo.org mailing list

On Wed, 2005-06-29 at 12:34 -0500, Josh Grebe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Dave and All,
>
> I'm sorry to say that I still crash reliably with this patch. Just to recap, it
> is a netra 1405, 4x440, 1G ram. Crashed after about 30 minutes of running my
> disk-loading crashme.sh.
>
> Josh

For completeness, I tried kernel version 2.6.13-rc1 (which has the
membar changes built in) on SB1000(2x900). Up time was under 10 minutes
before a hard lock. Just about any sort of heavy CPU/disk activity is
fatal (I was using a gimp rebuild as my stress test to a normally
running system (X, firefox, xchat, evolution, etc.), because gimp
rebuild for me is a pretty reliable kernel killer: On
U60(2x450)+membar, it took three rebuild attempts to get a successful
run to completion without a kernel suicide; SB1000+membar has never made
it more than a minute or so into a gimp build.)

>
>
>
> David S. Miller wrote:
> > [. CC:'ing Josh Grebe, he could reproduce these SMP hangs on
> > his box quite reliably ]
> >
> > Ok folks, give this patch a try. It applies cleanly to
> > 2.6.12 and 2.6.12.1
> >
> > [SPARC64]: Avoid membar instructions in delay slots.

Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

On Wed, 29 Jun 2005 15:28:04 +0000
Ferris McCormick <fmccor@gentoo.org> wrote:

> SB1000(2x900) --- With patch, under heavy load up time is measured in
> minutes (as under 10 minutes) consistently. Same kernel, but without
> patch, system seems stable.

I was able to replicate this problem with a Sun Blade 1000 (2x750 MHz
CPUs) as well. I shut off the syslog daemon, and the only thing that
showed up on the console was;

"Kernel panic - not syncing: Irrecoverable deferred error trap."

This showed up about a minute or so after the box stopped responding on
the console or via a remote SSH session.

Cheers,
--
Jason Wever
Gentoo/Sparc Team Co-Lead

From: Jason Wever <weeve@gentoo.org>
Date: Mon, 4 Jul 2005 18:39:17 -0600

> On Wed, 29 Jun 2005 15:28:04 +0000
> Ferris McCormick <fmccor@gentoo.org> wrote:
>
> > SB1000(2x900) --- With patch, under heavy load up time is measured in
> > minutes (as under 10 minutes) consistently. Same kernel, but without
> > patch, system seems stable.
>
> I was able to replicate this problem with a Sun Blade 1000 (2x750 MHz
> CPUs) as well. I shut off the syslog daemon, and the only thing that
> showed up on the console was;
>
> "Kernel panic - not syncing: Irrecoverable deferred error trap."

There should be a bunch of kernel log messages, each line starting
with "ERROR(..." right before this line gets printed out. Those
lines contain all of the information necessary to debug this.
Please try to capture them, thanks.
--
gentoo-sparc@gentoo.org mailing list

Nevermind, I found the bug. I subtly broke UltraSPARC-III and
later chips by accident.

This patch should fix it:

[SPARC64]: Fix __cheetah_flush_tlb_pending instruction count.

The recent membar changes broke the UltraSPARC-III code patching.

Signed-off-by: David S. Miller <davem@davemloft.net>

--- 1/arch/sparc64/mm/ultra.S.~1~ 2005-07-05 17:16:49.000000000 -0700
+++ 2/arch/sparc64/mm/ultra.S 2005-07-05 18:32:05.000000000 -0700
@@ -249,7 +249,7 @@
retl
wrpr %g7, 0x0, %pstate

-__cheetah_flush_tlb_pending: /* 22 insns */
+__cheetah_flush_tlb_pending: /* 23 insns */
/* %o0 = context, %o1 = nr, %o2 = vaddrs[] */
rdpr %pstate, %g7
sllx %o1, 3, %o1
@@ -317,7 +317,7 @@
sethi %hi(__cheetah_flush_tlb_pending), %o1
or %o1, %lo(__cheetah_flush_tlb_pending), %o1
call cheetah_patch_one
- mov 22, %o2
+ mov 23, %o2

#ifdef DCACHE_ALIASING_POSSIBLE
sethi %hi(__flush_dcache_page), %o0
--
gentoo-sparc@gentoo.org mailing list

From: Josh Grebe <squash@gentoo.org>
Date: Wed, 29 Jun 2005 12:34:27 -0500

> I'm sorry to say that I still crash reliably with this patch. Just
> to recap, it is a netra 1405, 4x440, 1G ram. Crashed after about 30
> minutes of running my disk-loading crashme.sh.

Thanks for testing...

Hmmm, so what else fundamentally changed in 2.6.x vs. 2.4.x
sparc64 wise? One thing that sticks out is that we do batched
TLB flushing now. That's kind of tricky to get right because
UltraSPARC requires that one does a "membar #Sync" or
"flush" after any internal cpu register store before any
subsequent non-internal load or store is performed.

We're slightly violating that in the new batched TLB flushing
code. So it's worth trying the patch below out.

This goes on top of the membar patch, and the UltraSPARC-III
fix for the membar patch. If there are some rejects, they'll
be minor and easy to fix up.

Let me know if this patch makes any difference.

[SPARC64]: Add missing "membar #Sync" to flush_tlb_pending().

flush_tlb_pending() (both the spitfire and cheetah variants)
need to do a membar after writing the context register, before
we load the first PTE entry in the batch array.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc64/mm/ultra.S b/arch/sparc64/mm/ultra.S
--- a/arch/sparc64/mm/ultra.S
+++ b/arch/sparc64/mm/ultra.S
@@ -57,6 +57,7 @@ __flush_tlb_pending:
mov SECONDARY_CONTEXT, %o4
ldxa [%o4] ASI_DMMU, %g2
stxa %o0, [%o4] ASI_DMMU
+ membar #Sync
1: sub %o1, (1 << 3), %o1
ldx [%o2 + %o1], %o3
andcc %o3, 1, %g0
@@ -250,7 +251,7 @@ __cheetah_flush_tlb_mm: /* 15 insns */
retl
wrpr %g7, 0x0, %pstate

-__cheetah_flush_tlb_pending: /* 23 insns */
+__cheetah_flush_tlb_pending: /* 24 insns */
/* %o0 = context, %o1 = nr, %o2 = vaddrs[] */
rdpr %pstate, %g7
sllx %o1, 3, %o1
@@ -260,6 +261,7 @@ __cheetah_flush_tlb_pending: /* 23 insns
mov PRIMARY_CONTEXT, %o4
ldxa [%o4] ASI_DMMU, %g2
stxa %o0, [%o4] ASI_DMMU
+ membar #Sync
1: sub %o1, (1 << 3), %o1
ldx [%o2 + %o1], %o3
andcc %o3, 1, %g0
@@ -318,7 +320,7 @@ cheetah_patch_cachetlbops:
sethi %hi(__cheetah_flush_tlb_pending), %o1
or %o1, %lo(__cheetah_flush_tlb_pending), %o1
call cheetah_patch_one
- mov 23, %o2
+ mov 24, %o2

#ifdef DCACHE_ALIASING_POSSIBLE
sethi %hi(__flush_dcache_page), %o0
@@ -367,6 +369,7 @@ xcall_flush_tlb_pending:
mov PRIMARY_CONTEXT, %g4
ldxa [%g4] ASI_DMMU, %g2
stxa %g5, [%g4] ASI_DMMU
+ membar #Sync
1: sub %g1, (1 << 3), %g1
ldx [%g7 + %g1], %g5
andcc %g5, 0x1, %g0
--
gentoo-sparc@gentoo.org mailing list

David S. Miller wrote:
> We're slightly violating that in the new batched TLB flushing
> code. So it's worth trying the patch below out.
>
> This goes on top of the membar patch, and the UltraSPARC-III
> fix for the membar patch. If there are some rejects, they'll
> be minor and easy to fix up.
>
> Let me know if this patch makes any difference.

It makes a difference alright. My machine craters in the crashme after
about 10 minutes.

locked so hard I can't even sysreq umount/sync/reboot

I've enclosed the cpuinfo and dmesg output from bootup.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave and All,

First run it took about 2 hours to crash. I thought it might be an improvement,
so I ran it again and it only took 1 hour to crash... Which is about the average
it was taking before. Otherwise it looks the same I'm afraid.

Josh


David S. Miller wrote:
>
> Let me know if this patch makes any difference.
>
> [SPARC64]: Add missing "membar #Sync" to flush_tlb_pending().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzXvyFAhB33r2ACYRApxBAJ4lAjBNgSxSJgrRB85Azpvt+BJbRgCffYWq
oO7j6y3j/VzHgnuGKi//VXs=
=mv7I
-----END PGP SIGNATURE-----
--
gentoo-sparc@gentoo.org mailing list

From: Josh Grebe <squash@gentoo.org>
Date: Thu, 07 Jul 2005 14:01:06 -0500

> First run it took about 2 hours to crash. I thought it might be an
> improvement, so I ran it again and it only took 1 hour to
> crash... Which is about the average it was taking before. Otherwise
> it looks the same I'm afraid.

Ok, thanks a lot for testing.
--
gentoo-sparc@gentoo.org mailing list

From: "David S. Miller" <davem@redhat.com>
Subject: Re: [gentoo-sparc] 2.6 kernel and docs
Date: Thu, 07 Jul 2005 16:12:53 -0400 (EDT)

> From: Josh Grebe <squash@gentoo.org>
> Date: Thu, 07 Jul 2005 14:01:06 -0500
>
> > First run it took about 2 hours to crash. I thought it might be an
> > improvement, so I ran it again and it only took 1 hour to
> > crash... Which is about the average it was taking before. Otherwise
> > it looks the same I'm afraid.
>
> Ok, thanks a lot for testing.

Josh, others, give me a little help for a second.

Can you guys clearly state that 2.6.8 is basically when the problems
started to surface? This would be an important clue.

I seem to remember a lot of talk about "2.6.7 is fine".

Thanks a lot.
--
gentoo-sparc@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave,

2.6.5 is the first kernel that compiles for sparc64, and it
exhibits the same issue (I just tried starting from 2.6.1
and worked my way up).

For the sake of completeness, I also tested 2.6.7, and it
crashed in record time (17 minutes!)

So I'd offer that the "2.6.7 is fine" bit was just noise.

Josh


David S. Miller wrote:
> From: "David S. Miller" <davem@redhat.com>
> Subject: Re: [gentoo-sparc] 2.6 kernel and docs
> Date: Thu, 07 Jul 2005 16:12:53 -0400 (EDT)
>
>
>>From: Josh Grebe <squash@gentoo.org>
>>Date: Thu, 07 Jul 2005 14:01:06 -0500
>>
>>
>>>First run it took about 2 hours to crash. I thought it might be an
>>>improvement, so I ran it again and it only took 1 hour to
>>>crash... Which is about the average it was taking before. Otherwise
>>>it looks the same I'm afraid.
>>
>>Ok, thanks a lot for testing.
>
>
> Josh, others, give me a little help for a second.
>
> Can you guys clearly state that 2.6.8 is basically when the problems
> started to surface? This would be an important clue.
>
> I seem to remember a lot of talk about "2.6.7 is fine".
>
> Thanks a lot.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://enigmail.mozdev.org

iD8DBQFCzgHZFAhB33r2ACYRAq7UAJ0V5qXxyoCHrMnWF1QDai+dcVenYgCgkc1O
qfPeJzreqSJ698qqaiAyROg=
=47y9
-----END PGP SIGNATURE-----
--
gentoo-sparc@gentoo.org mailing list

From: Josh Grebe <squash@gentoo.org>
Date: Thu, 07 Jul 2005 23:32:26 -0500

> 2.6.5 is the first kernel that compiles for sparc64, and it
> exhibits the same issue (I just tried starting from 2.6.1
> and worked my way up).

If you can work out the build failure in 2.6.1, it ought to
be incredibly easy to fix, can you try getting it to build
properly? Send me whatever error messages you get if you
get stumped, and if it's matter of simply turning off a
kernel config option that you don't need in order to avoid
trying to build the uncompilable code in 2.6.1 just do that
instead.

We really need to figure out when and where this got introduced.
I'm just stabbing in the dark otherwise. We can go back into
the 2.5.x kernels and do a binary search as well if necessary.
I'll try to help with that.

Thanks.
--
gentoo-sparc@gentoo.org mailing list

> --- Ursprüngliche Nachricht ---
> Von: "David S. Miller" <davem@redhat.com>
> An: squash@gentoo.org
> Kopie: gentoo-sparc@lists.gentoo.org
> Betreff: Re: [gentoo-sparc] 2.6 kernel and docs
> Datum: Fri, 08 Jul 2005 00:36:21 -0400 (EDT)
>
> From: Josh Grebe <squash@gentoo.org>
> Date: Thu, 07 Jul 2005 23:32:26 -0500
>
> > 2.6.5 is the first kernel that compiles for sparc64, and it
> > exhibits the same issue (I just tried starting from 2.6.1
> > and worked my way up).
>
> If you can work out the build failure in 2.6.1, it ought to
> be incredibly easy to fix, can you try getting it to build
> properly? Send me whatever error messages you get if you
> get stumped, and if it's matter of simply turning off a
> kernel config option that you don't need in order to avoid
> trying to build the uncompilable code in 2.6.1 just do that
> instead.
>
> We really need to figure out when and where this got introduced.
> I'm just stabbing in the dark otherwise. We can go back into
> the 2.5.x kernels and do a binary search as well if necessary.
> I'll try to help with that.
>
> Thanks.
> --
> gentoo-sparc@gentoo.org mailing list
>

I want to run the crash-me.sh file on my own machines, but I am wondering
what permanent damage it would do to the systems involved?
AFAIK no system files are affected by the copy action etc, but is this true?

I have two machines running 2.6.6, a Ultra 1 and a Netra T1.
Since a while the Ultra 1 has a 100MBit link and transferring quite large
amounts of FTP data hasn't crashed the system yet. It runs perfectly.

Anyway, if I can hook up my Netra T1 tonight I will run the crash-me.sh
file.

Regards,

Tom

--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
--
gentoo-sparc@gentoo.org mailing list

freshy98 wrote:

> I want to run the crash-me.sh file on my own machines, but I am wondering
> what permanent damage it would do to the systems involved?
> AFAIK no system files are affected by the copy action etc, but is this true?
>
> I have two machines running 2.6.6, a Ultra 1 and a Netra T1.
> Since a while the Ultra 1 has a 100MBit link and transferring quite large
> amounts of FTP data hasn't crashed the system yet. It runs perfectly.
>
> Anyway, if I can hook up my Netra T1 tonight I will run the crash-me.sh
> file.

If in doubt about possible filesystem corruption, deactivate swap, make
a filesystem there and do it there. That way it won't matter.

--
Gustavo Zacarias
Gentoo/SPARC monkey
--
gentoo-sparc@gentoo.org mailing list

> --- Ursprüngliche Nachricht ---
> Von: Gustavo Zacarias <gustavoz@gentoo.org>
> An: gentoo-sparc@lists.gentoo.org
> Betreff: Re: [gentoo-sparc] 2.6 kernel and docs
> Datum: Fri, 08 Jul 2005 10:05:33 -0300
>
> freshy98 wrote:
>
> > I want to run the crash-me.sh file on my own machines, but I am
> wondering
> > what permanent damage it would do to the systems involved?
> > AFAIK no system files are affected by the copy action etc, but is this
> true?
> >
> > I have two machines running 2.6.6, a Ultra 1 and a Netra T1.
> > Since a while the Ultra 1 has a 100MBit link and transferring quite
> large
> > amounts of FTP data hasn't crashed the system yet. It runs perfectly.
> >
> > Anyway, if I can hook up my Netra T1 tonight I will run the crash-me.sh
> > file.
>
> If in doubt about possible filesystem corruption, deactivate swap, make
> a filesystem there and do it there. That way it won't matter.
>
> --
> Gustavo Zacarias
> Gentoo/SPARC monkey
> --
> gentoo-sparc@gentoo.org mailing list
>

Ok, will try that one. swap is kinda big on the T1 anyway since it only has
256MB RAM. I believe I made swap 1GB there.


--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
--
gentoo-sparc@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave,

I got 2.6.1 to build, and after disabling PROM console and serial port support,
I got it to boot. 2.6.1 crashed within about 20 minutes of starting crashme.sh.

The compile errors were actually warnings in arch/sparc64/kernel and
arch/sparc64/mm which compiles with -Werror plus one include.

I'm going to start on 2.5 kernels from the bottom... Theres a damn lot of them,
so it will take some time.

Thanks,

Josh


David S. Miller wrote:
> From: Josh Grebe <squash@gentoo.org>
> Date: Thu, 07 Jul 2005 23:32:26 -0500
>
>
>>2.6.5 is the first kernel that compiles for sparc64, and it
>>exhibits the same issue (I just tried starting from 2.6.1
>>and worked my way up).
>
>
> If you can work out the build failure in 2.6.1, it ought to
> be incredibly easy to fix, can you try getting it to build
> properly? Send me whatever error messages you get if you
> get stumped, and if it's matter of simply turning off a
> kernel config option that you don't need in order to avoid
> trying to build the uncompilable code in 2.6.1 just do that
> instead.
>
> We really need to figure out when and where this got introduced.
> I'm just stabbing in the dark otherwise. We can go back into
> the 2.5.x kernels and do a binary search as well if necessary.
> I'll try to help with that.
>
> Thanks.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzte4FAhB33r2ACYRApURAJ9EPAGJDkbFLMzw3yYloPzjkbgCUwCfVwxI
8abdEFEjneoM+Upa+4Ei+mw=
=XPog
-----END PGP SIGNATURE-----
--
gentoo-sparc@gentoo.org mailing list

From: Josh Grebe <squash@gentoo.org>
Date: Fri, 08 Jul 2005 14:44:56 -0500

> I got 2.6.1 to build, and after disabling PROM console and serial port support,
> I got it to boot. 2.6.1 crashed within about 20 minutes of starting crashme.sh.
>
> The compile errors were actually warnings in arch/sparc64/kernel and
> arch/sparc64/mm which compiles with -Werror plus one include.
>
> I'm going to start on 2.5 kernels from the bottom... Theres a damn lot of them,
> so it will take some time.

Thanks a lot Josh.
--
gentoo-sparc@gentoo.org mailing list