Re: XFree86 problems on an Indy
On Mon, Jun 18, 2001 at 09:37:15PM +0200, Klaus Naumann wrote:
> On Mon, 18 Jun 2001, Manuel Estrada Sainz wrote:
>
> > o With the prebuilt kernel (from ftp.rfc822.org) over time (a day or
> > so) and heavy load (a kernel build) I get masive filesystem
> > corruption, so I am going diskless for now (it seams that the new
> > kernel from cvs also has problems with this).
> > In case this helps, this happend on the second scsi disk of a single
> > controler, kernel output:
>
> This is our well known "Multiple Disk Problem" (It's the official name).
> If you use more than one Disk per controller actively (= have it mounted
> and copy files between the disks) very bad things will happen.
> Don't do that - you should do what I do at the moment: Mount the root
> over NFS and mount __one__ harddisk and use that.
I still have problems, but it is probably the ext2 problem, I'll try with
linux_2_4_4 and linux_2_4_3 from the CVS.
Could it be a problem if the disk I use is the second on the controler?
Or as long as I use a single disk it doesn't matter which?
Is it so important to boot over NFS?
Would it be a problem reading the kernel from the vh?
What would be the problem if I boot directly from the disk and I leave the
other disk alone?
> > o I am getting strange console behavior with my home built kernel from
> > latest sgi cvs (mostly sure this is my fault).
> >
> > I don't get any output from the boot scripts, the last message I
> > see on the little blue square is: Freeing unused kernel memory:...
> > And the next thing I see is a login prompt and the top left
> > corner. Is console output going somewhere else? Should I change
> > /dev/console?
>
> This sounds odd and should not happen. Can you check if your /dev/console
> is looking like this:
>
> root@ivy:/mnt/build# ls /dev/console -l
> crw------- 1 root tty 5, 1 Jun 16 2001 /dev/console
/dev/console is right, it is the kernel's default which has changed, if I
give it console=tty0 it works.
> >
> > o OSLoadOptions just rembers the first 12 chars of its contents when
> > rebooting, but SystemPartition remembers 35 without problem. I know
> > that this is probably the know issue, but how can I give the kernel
> > parameters if they don't feet?
> > Maybe I could unset some variables to free some memory or use
> > OSLoadPartition to pass some parameters.
>
> Hmm, my guess would be, that this is a Problem with the PROM itself.
> Maybe you should take a look at dvhtool ...
I will use dvhtool, but I may have some good news:
I was able to use SystemPartition to pass more parameters to the kernel,
since SystemPartition is used by the kernel as: root=$SystemPartition
I could happily stuff some parameters after /dev/nfsroot:
setenv SystemPartition "/dev/nfsroot nfsroot=xx.xx.xx.xx:/xx/xx/ rw"
Or even omit the root device by prepending a space and using all the variable
for extra parameters:
setenv SystemPartition " nfsroot=xx.xx.xx.xx:/xx/xx/ rw"
Is there some way to make the PROM forget about "netaddr"?
My dhcp server is version 2.0 with the corresponding bug and I have to
manualy "unsetenv netaddr" every time I boot through bootp and everytime the
PROM sets it again.
> > o I compiled the kernel with the cross devel rpm packages at sgi, is
> > that ok or what gcc/binutils should I use? Is it ok to build the
> > kernel with gcc-2.95.4 natively?
>
> Yes, this works ok - at least for me. The only problem is that
> with current cvs kernel the nfs root seems to be fscked somehow.
> You need to give the option ip=bootp or ip=dhcp at bootup to enable
> bootp or dhcp - but it doesn't work then either.
> Please tell me if you see this too if you try current cvs.
Nop, it doesn't work for me either.
I tryied with ip=bootp, ip=dhcp, ip=auto and the only thing which worked was
manualy giving it the IP:
ip=xxx.xxx.xxx.xxx
Thanks
ranty
--
--- Manuel Estrada Sainz <ranty@debian.org>
<ranty@atdot.org>
------------------------ <ranty@soon.com> ---------------------------------
God grant us the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
Reply to: