Hi,
I have not played with the config for the generic
kernel since I did a complete reinstall. I'll try that
out since I did not install gcc. Perhaps egcs will
sort out the issue, we'll see.
--- Chris Lumens <chris@slackware.com> wrote:
> > If I create a very mimimal configuration that only
> just support the
> > hardware I have, then it does not Oops. I don't
> know exactely what option
> > I'm excluding that causes the Oops seen
> previously, but that should be
> > possile to work out once I get it to boot
> completely (see below).
> > With the minimal config the kernel works no matter
> if it's GENERIC or
> > Avanti, which I think is good news :-).
>
> Yes, that is good news.
>
> > Although the kernel no longer Oopses, I can still
> not boot it as it now
> > seems to have some problems with my scsi
> controller. I have tried
> > everything from the most conservative settings to
> the most agressive, but
> > no matter what I choose it hangs at boot with this
> message:
> >
> > scsi : aborting command due to timeout : pid 0,
> scsi0, channel 0, id 0,
> > lun
> > 0 Test Unit Ready 00 00 00 00 00
>
> I've had issues like this before on aic7xxx
> controllers (both on Alpha and
> Intel). The solution appears to either be: upgrade
> the scsi code, or just
> reset the machine. I've had this problem before on
> my Alpha, and I was
> able to get around it by just rebooting the machine.
> Sometimes, this
> didn't work though. Stupid flaky drivers...
>
> > I have also tried the exact same settings that the
> debian kernel use
> > (which boots fine on this box), but that does not
> work either - which
> > seems very strange to me.
>
> If the Debian kernel boots, but their config file
> doesn't reproduce a
> working kernel, that is very strange. What compiler
> are you using to
> build these kernels? I had gcc 2.95.2 in the
> distribution for a while,
> but it created such a horrible mess of c++ code that
> I was forced to throw
> it back into contrib.
>
> > I tried upgrading to the latest 2.2.18pre kernel,
> but that one has the
> > same scsi issue (although it uses a newer version
> of the driver).
>
> Does the newer kernel version still have problems
> with the generic config
> file?
>
> > ncr53c8xx: at PCI bus 0, device 6, function 0
> > ncr53c8xx: 53c810 detected
> > ncr53c810-0: rev=0x01, on pci bus 0 device 6
> function 0 irq 11
> > ncr53c810-0: ID 7, Fast-10, Parity Checking
> > scsi0 : ncr53c8xx-3.4.1-20000726
> > scsi : 1 host.
> > scsi : aborting command due to timeout : pid 0,
> scsi0, channel 0, id 0,
> > lun
> > 0 Test Unit Ready 00 00 00 00 00
> > ncr53c8xx_abort: pid=0 serial_number=1
> serial_number_at_timeout=1
>
> Have you looked to see if there are any kernel
> options you can pass at
> boot time? I know the Adaptec controller drivers
> support the
> aic7xxx=no_reset (I think that's the proper syntax)
> option. That
> sometimes works where there's all these timeout
> issues. Maybe the NCR
> drivers support a similar option.
>
> > Unfortunately the kernel I'm using to boot is not
> compiled with support
> > for the ATI Mach64, so I cannot use the
> Framebuffer X server.
>
> If the kernel is compiled with VESA framebuffer
> support, you can use that
> to run the X framebuffer server. The VESA
> framebuffer is a generic one
> that will work with any VESA-compliant video cards.
> You can try to use
> that by passing a video= option to the kernel.
> Then, a framebuffer X
> config file is provided during Slackware
> installation as
> /etc/XF86Config-fbdev.
>
> > All the
> > other servers refuse to start, with the exception
> of the mono server and
> > the Mach64 server. The mono server starts but
> presents me with a
> > completely messed up screen, and starting the
> Mach64 server has the
> > effect of dumping me straight back in the SRM
> console.
> > The graphics card in this box is a ISA based
> Mach64 GX (chip is:
> > 210888GX00, RamDac is: AT&T PrecisionDAC
> ATT20C408-13).
>
> During xf86config, there's an option to choose a
> Ramdac. Did you do that?
> If not, try doing so. If you did, try removing that
> option. I enabled a
> ramdac on my test machine with an S3 card, and the
> result was that it
> didn't work at all. Removing that option got X
> running just fine. So,
> you may need to tweak those options.
>
> Additionally, I could throw together a very sloppy X
> package, built with
> all the CFLAGS out of the RedHat spec file for
> testing purposes. That
> could at least rule out any problems as a result of
> what machine it was
> compiled on.
>
> --
> Chris Lumens - chris@slackware.com - KG6CIH
>
@n=(-42,-85,-83,-19,65,2,-10,-10,-15,-3,2,-10,73,-4,8,-4,2,79,8,17,15,7,14,2);
> print map{chr(-$n[$i++]+ord)} sort(split(//,'place
> random string here')),"\n";
>
=====
******************************************************
* Octave J. Orgeron * Specializing in : *
* Unix Systems Administrator * Solaris/Tru64/Linux *
* Sun Microsystems, Inc. * Certified Solaris *
* octave@sun.com * Systems Administrator *
******************************************************
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
This archive was generated by hypermail 2b30 : Fri May 09 2003 - 10:00:02 PDT