RE: An (flamebait ?) idea to preserve debian on sparc32...
- To: Steve <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: RE: An (flamebait ?) idea to preserve debian on sparc32...
- From: Jurij Smakov <firstname.lastname@example.org>
- Date: Sun, 31 Jul 2005 09:39:21 -0400 (EDT)
- Message-id: <Pine.LNX.4.61.0507310926190.2932@bobcat>
- Reply-to: email@example.com
- In-reply-to: <000801c5948a$91e57960$0200a8c0@dell8200a>
- References: <000801c5948a$91e57960$0200a8c0@dell8200a>
On Sat, 30 Jul 2005, Steve wrote:
Well, I have mailed to this list before and said ...
I have a SPARC 4 sun4m working quite happily with the 2.6.12-1-sparc32
kernel running a fully upgraded sarge installation. Perhaps the reason
for it being so happy is because this box is just being used a
DNS/Syslog server with no monitor attached.
Anyway, I shall continue to drop this bit of info into the list until
someone explains why there seem to be so many issues when it would
appear this box will run quite happily for quite some time before
problems arise regarding new kernels or OS releases. Always willing to
Unfortunately, the good old QA standard "it works for me" does not apply
in this case :-). I am aware of multiple problems with this kernel. To
mention a few:
* The kernel you tested does not have initrd support, unlike other Debian
kernels. I could not boot it with initrd (panic on boot), so I disabled
it. 2.4.27 boots fine with initrd.
* Debugging of the initrd problem indicated that occasionally (not every
time, so you can be just lucky) the basic memory-copying routine
corrupts the data it copies. That's a very serious problem, and I don't
know an easy way to fix it. I suspect that this is responsible for the
filesystem corruption under heavy load, I can reliably trigger it by
dist-upgrade, and in this case it corrupts dpkg status files, which
usually requires a reinstallation.
* I have an independent confirmation, that the success/failure of 2.6.12
kernel to boot is correlated to the locations of the memory chips in the
I don't think it is acceptable to release a kernel with problems like
these to our users.
Jurij Smakov firstname.lastname@example.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC