Subject: RE: Re: RAQ2 boot problem
To: None <port-cobalt@netbsd.org>
From: None <paulmac2@aol.com>
List: port-cobalt
Date: 09/05/2005 11:36:43
----------MailBlocks_8C78046C08B7CF2_4CC_870E_mblk-d33.sysops.aol.com
Content-Type: text/plain; charset="us-ascii"
>Sorry to possibly state the obvious, but the firmware boots the NetBSD
>bootloader, and the bootloader boots the kernel in the NetBSD root
>partition right? A lot of people still seem stuck on trying to make a
>kernel to fit on the Linux boot partition (as I was in the beginning),
>so I'm hoping we can start clearing up that you don't need to do
>that...
Yes, the bootloader vmlinux.gz and kernel netbsd are in the right places
(/boot in the ext2fs and / in the NetBSD fs).
>> Kernelized RAIDframe activated
>> scsibus0: waiting 2 seconds for devices to settle...
>> wd0 at atabus0 drive 0INTRF
>> panic: siop_intr: I shouldn't be there !
>> Stopped at netbsd:cpu_Debugger+0x4: jr ra
>> bdslot: nop
>>
>> db>
>
>Well, this could be a few things. I'm not really smart enough about
>the code to know what those messages mean after the panic, but I think
>siop is related to the scsi controller. If you you expect not to use
>scsi, you might try commenting out the siop controller:
>
>siop* at pci? dev ? function ? # NCR 53c8xx SCSI
>and
>scsibus* at siop?
>
>> How have other people been able to get this to work? If I should be using a
>> different
>> kernel, I'll need to know how to build it because I'm going to have to do it
>> again to add
>> IP forwarding, IPF and PPP.
>
>I don't have the RAQ, so I don't use scsi at all.
>
>First question is, have you ever built a kernel? Having experience
>with building one on another machine would be helpful. But mostly you
>want to do it with build.sh in the root of the source tree.
I've built 1.n kernels on MIPS and other hardware. What I did then was boot the
generic kernel, then tailor on or off the features I wanted by building a new kernel
later. But it sounds like either my SCSI controller is returning a condition that the
new kernel isn't dealing with very well or the new kernel just doesn't work well with
SCSI. In either case, disabling the SCSI features by building a new kernel beforehand
seems to be the only workaround.
--
:p.
----------MailBlocks_8C78046C08B7CF2_4CC_870E_mblk-d33.sysops.aol.com
Content-Type: text/html; charset="us-ascii"
<HTML><BODY><DIV style='font-family: "Verdana"; font-size: 10pt;'><DIV>
<DIV>>Sorry to possibly state the obvious, but the firmware boots the NetBSD<BR>>bootloader, and the bootloader boots the kernel in the NetBSD root<BR>>partition right? A lot of people still seem stuck on trying to make a<BR>>kernel to fit on the Linux boot partition (as I was in the beginning),<BR>>so I'm hoping we can start clearing up that you don't need to do<BR>>that...</DIV>
<DIV> </DIV>
<DIV>Yes, the bootloader vmlinux.gz and kernel netbsd are in the right places<BR>(/boot in the ext2fs and / in the NetBSD fs).<BR> <BR>>> Kernelized RAIDframe activated <BR>>> scsibus0: waiting 2 seconds for devices to settle... <BR>>> wd0 at atabus0 drive 0INTRF <BR>>> panic: siop_intr: I shouldn't be there ! <BR>>> Stopped at netbsd:cpu_Debugger+0x4: jr ra <BR>>> bdslot: nop <BR>>> <BR>>> db> <BR>><BR>>Well, this could be a few things. I'm not really smart enough about<BR>>the code to know what those messages mean after the panic, but I think<BR>>siop is related to the scsi controller. If you you expect not to use<BR>>scsi, you might try commenting out the siop controller:<BR>><BR>>siop* at pci? dev ? function ? # NCR 53c8xx SCSI<BR>>and<BR>>scsibus* &
nbsp; at siop?<BR>><BR>>> How have other people been able to get this to work? If I should be using a<BR>>> different <BR>>> kernel, I'll need to know how to build it because I'm going to have to do it<BR>>> again to add <BR>>> IP forwarding, IPF and PPP. <BR>><BR>>I don't have the RAQ, so I don't use scsi at all.<BR>><BR>>First question is, have you ever built a kernel? Having experience<BR>>with building one on another machine would be helpful. But mostly you<BR>>want to do it with build.sh in the root of the source tree.</DIV>
<DIV> </DIV>
<DIV>I've built 1.n kernels on MIPS and other hardware. What I did then was boot the</DIV>
<DIV>generic kernel, then tailor on or off the features I wanted by building a new kernel</DIV>
<DIV>later. But it sounds like either my SCSI controller is returning a condition that the</DIV>
<DIV>new kernel isn't dealing with very well or the new kernel just doesn't work well with</DIV>
<DIV>SCSI. In either case, disabling the SCSI features by building a new kernel beforehand</DIV>
<DIV>seems to be the only workaround.<BR>--<BR>:p.</DIV></DIV></DIV></BODY></HTML>
----------MailBlocks_8C78046C08B7CF2_4CC_870E_mblk-d33.sysops.aol.com--