Hey.. good news.. maybe.. 2.2.18 kernel is out!
Here is a list of the fixes that are Alpha related.
I'm going to download this and start compiling away..
and continue to track down the problem with making a
generic kernel.
o Fix missing Alpha includes
(Matt Wilson)
o Fix missing symbols on alpha
(Matt Wilson)
o Fix alpha compile problem
(Herbert Xu)
o Fix FAT32 bugs on Alpha
(Bill Nottingham)
o Fix irongate handling on Alpha
(Soohoon Lee)
o Fix AGP oops on Alpha
(Michal Jaegermann)
o Fix alpha loops per jiffy
(Jay Estabrook)
o Fix alpha generic trident sound support
(Rich Payne)
o Alpha FPU divide fix
(Richard Henderson)
o Fix Alpha for loops_per_jiffy
(Willy Tarreau)
o Alpha PCI boot up fix
(Michal Jaegermann)
o Fix Alpha vmlinuz.lds
(Andrea Arcangeli)
o Fix bug in alpha csum_partial_copy that could
(Herbert Xu)
o Make msnd_pinnacle driver build on Alpha
o Fix trident driver build on nautilus Alpha
(Peter Petrakis)
--- Jesper Juhl <juhl@eisenstein.dk> wrote:
>
> If you manage to do a 'make oldconfig' on the debian
> config file, then
> I'd very much like to know how. I'm getting lot of
>
> : command not found
> : command not found
> : command not found
>
> errors when I do that, so I went through the debian
> config with less and
> set each option in another virtual console through
> 'make menuconfig'
> according to the settings in the debian file - that
> took quite a while
> :-(
>
>
> /Jesper Juhl
>
>
> >>>>>>>>>>>>>>>>>> Oprindelig meddelelse
> <<<<<<<<<<<<<<<<<<
>
> Den 12/11/00, 11:25:13 AM, skrev Octave Orgeron
> <unixconsole@yahoo.com> til
> emnet Re: [slackware-alphadevel] kernels, x:
>
> > 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.
> > >
>
=== message truncated ===
=====
******************************************************
* 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