On Fri, 13 Jun 2003, Ben Collins wrote:
suspect you did something wrong though. Try my
kernel-image-2.4.21-sparc64 package. If that works, use the
/boot/config-2.4.21 as a starting point for compiling your own.
Any hint what would be the right compiler for a woody machine?
Kind regards
On Sat, Jun 14, 2003 at 03:06:20PM +0200, Andreas Tille wrote:
On Fri, 13 Jun 2003, Ben Collins wrote:
suspect you did something wrong though. Try my
kernel-image-2.4.21-sparc64 package. If that works, use the
/boot/config-2.4.21 as a starting point for compiling your own.
Any hint what
On Sat, Jun 14, 2003 at 11:24:58AM +0200, David List wrote:
I am aware that this may very well be a hardware problem, but I am not
sure that it is, and I believe there is a very good possibility that one
or more in this group have had to fight a similar problem, so now I try:
I have
Hello.
After reading the changelogs for the final release version of 2.4.21 and
seeing lots of fixes for sparc, I decided it was time to try upgrading
from the stock debian 2.2.20 kernel on my SS20 SMP box.
The compilation and installation went fine using make-kpkg. However, I'm
having the
I wish I had seen this thread before I rebooted into a 2.4.21 kernel
compiled with gcc 3.3. The x86 kernel compiles fine with 3.3, I was
under the assumption that sparc would be fine as well. Now I rebooted
without access to the machine, and I can't bring it up into the backup
kernel until
On Sat, 14 Jun 2003, Ben Collins wrote:
You need to send the dmesg of the drives detection, so we can see what
the kernel thinks.
I have inserted it below.
There is a line in the dmesg output that actually tells the right data
on the harddrive. I gather that means that the kernel *is* able to
On Sat, Jun 14, 2003 at 05:09:33PM +0200, David List wrote:
On Sat, 14 Jun 2003, Ben Collins wrote:
You need to send the dmesg of the drives detection, so we can see what
the kernel thinks.
I have inserted it below.
There is a line in the dmesg output that actually tells the right data
I just tftpbooted the images from
http://auric.debian.org/~bcollins/disks-sparc/current/
The standard boot images would crash while booting.
That's helpful. I found that the stock images were not recognized by
the OpenBoot firmware. Not exactly a crash, but neither were they
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
I have installed a Maxtor Diamondmax Plus 9 (80 GB)
in my Ultra 5 and I cannot get Linux fdisk to see more that about 13.5
GB of the drive. I am using Debian 3.0_r1.
The bug is in the ide standard. Early Ultra-5 systems are older than
the
On Sat, Jun 14, 2003 at 09:03:19AM -0700, Marc Singer wrote:
I just tftpbooted the images from
http://auric.debian.org/~bcollins/disks-sparc/current/
The standard boot images would crash while booting.
That's helpful. I found that the stock images were not recognized by
the
On Sat, 14 Jun 2003, Ben Collins wrote:
Yeah, do the fdisk sun label thing. If the kernel can see, it, then so
can fdisk. The reason it wouldn't before is probably because Solaris put
a bad disk label on there.
I took out the drive, put it into a running system, made one big ext2
partition on
One other thing. I've heard that the performance of Ultrasparc Linux
is not expected to be as good as Solaris because user-mode Sparc
binaries run in a 32 bit mode. How do you feel about how well Linux
runs on the Ultrasparc?
On Sun, Jun 15, 2003 at 04:05:03AM +1000, Jamie Lenehan wrote:
On Sat, Jun 14, 2003 at 09:03:19AM -0700, Marc Singer wrote:
I just tftpbooted the images from
http://auric.debian.org/~bcollins/disks-sparc/current/
The standard boot images would crash while booting.
13 matches
Mail list logo
