[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian and Adaptec 294x



Mail 1:

Hello Adam, thank you for your mail.
You have 3 questions:

> Should we just grab your rescue image?

  Please do. But if you have a decent fast machine why not reproduce the
  steps below. The steps are quite simple. As a bonus you will know exacly
  what you have -- you don't really know what's in that image on my ftp
  site.

> Is it based on 2.1.9 or later (CVS) updates?

  It is based on the 2.1.9-1999-03-03/resc1440.bin as found on
  ftp.lh.umu.se. 
   
> Do we need a drivers disk too?

  Only compiled in SCSI card drivers was removed, nothing with M in
  the menuconfig choises was touched, as to be able to use the same
  drivers disk.
  To be more specific I went to:

  SCSI support  --->
  SCSI low-level drivers  --->

  And removed every <*> marked driver except the one for the AIC7xxx and
  the resulting screen was as seen below.

  *ALL* other stuff was unchanged.

---------------------------
Mail 2:

Well tonight they was there:

  --- karl@kalle --- ~ --- 02:24:17 ---
  $ cd /home/ftp/pub/
  --- karl@kalle --- /home/ftp/pub --- 02:24:20 ---
  $ ls
  kurs                         resc1440.bin-only-aic7xxx
  vmlinuz-2.0.36-only-aic7xxx
  --- karl@kalle --- /home/ftp/pub --- 02:24:20 ---
  $ lsl
  total 1948
  drwxrwxr-x   3 karl     users        1024 maj 24 06:38 kurs/
  -rw-r--r--   1 karl     users     1474560 jun 17 18:28 resc1440.bin-only-aic7xxx
  -rw-r--r--   1 karl     users      508194 jun 17 18:32 vmlinuz-2.0.36-only-aic7xxx
  --- karl@kalle --- /home/ftp/pub --- 02:24:24 ---
  $ date
  mån jul 12 02:27:48 CEST 1999
  --- karl@kalle --- /home/ftp/pub --- 02:27:48 ---
  $

From: Eric <brain@leading.net>
http://www.debian.org/Lists-Archives/debian-testing-9906/msg00020.html
reported success.

From: "A. P. Garcia" <apg@execpc.com> 
http://www.debian.org/Lists-Archives/debian-testing-9907/msg00004.html
reported
> The boot is getting hosed in the eata_detect function of the eata-dma
> driver (eata_dma.c).
for the standard resc disc.

I have heard of no other successes or pointers to the original problems.
I (or we) might do a similar disk for a non-eata resc to verify
A.P.Garcia's comment.
   
Sincerely,
/Karl

-------------------------------------------------------------------------------
Karl Hammar             Aspö Data               karl@kalle.csb.ki.se
Lilla Aspö 2340         +46 173 140 57
S-742 94 Östhammar                              Professional Linux Solutions
Sweden                  +46 70 511 97 84 (mobile)
-------------------------------------------------------------------------------

Menuconfig SCSI low-level drivers screen after my mods:

< > 7000FASST SCSI support
< > Adaptec AHA152X/2825 support
< > Adaptec AHA1542 support
< > Adaptec AHA1740 support
<*> Adaptec AIC7xxx support
[ ]    Enable Tagged Command Queueing (TCQ) by default
(8)    Maximum number of TCQ commands per device
[*]    Collect statistics to report in /proc
(15)    Delay in seconds after SCSI bus reset
< > AdvanSys SCSI support
< > Always IN2000 SCSI support
< > AM53/79C974 PCI SCSI support
< > AMI MegaRAID support
< > BusLogic SCSI support
< > DTC3180/3280 SCSI support
< > EATA-DMA (DPT, NEC, AT&T, SNI, AST, Olivetti, Alphatronix) support
< > EATA-PIO (old DPT PM2001, PM2012A) support
< > EATA ISA/EISA/PCI (DPT and generic EATA/DMA-compliant boards) support
< > Future Domain 16xx SCSI support
<M> Generic NCR5380/53c400 SCSI support
[ ]    Enable NCR53c400 extensions
(Port) NCR5380/53c400 mapping method (use Port for T130B)
<M> NCR53c406a SCSI support
< > NCR53c7,8xx SCSI support
< > NCR53C8XX SCSI support
[ ] IBMMCA SCSI support
<M> IOMEGA Parallel Port ZIP drive SCSI support
[ ]   Buggy EPP chipset support
< > PAS16 SCSI support
< > Qlogic FAS SCSI support
< > Qlogic ISP SCSI support
< > Seagate ST-02 and Future Domain TMC-8xx SCSI support
< > Tekram DC-390(T) SCSI support
< > Trantor T128/T128F/T228 SCSI support
< > UltraStor 14F/34F support
< > UltraStor SCSI support
< > GDT SCSI Disk Array Controller support


Mail 1:
On 10 Jul 1999, Adam Di Carlo wrote:

> 
> Herbert, I apologize, I think you were right.  According to
> Debian-testing group, the following kernel/rescue disk seems to work
> quite well.
> 
> Karl, I'd like to provide your rescue image in the Debian archive
> proper (i.e., dists/stable/disks-i386/current/aha/ ?).  Should we just
> grab your rescue image?  Is it based on 2.1.9 or later (CVS) updates?
> Do we need a drivers disk too?
> 
> 
> "Karl B. Hammar" <karl@kalle.csb.ki.se> writes:
> > Your message says me that the 7000FASST might not be the cause of the
> > problem.
> > 
> > Well, try this one then
> > 
> > # cp .config.save .config
> > # make menuconfig # remove all compiled in SCSI support except aic7xxx
> > # make dep; make clean; make zImage
> > # mv arch/i386/boot/zImage vmlinuz-2.0.36-only-aic7xxx
> > 
> >   available as ftp://kalle.csb.ki.se/pub/vmlinuz-2.0.36-only-aic7xxx
> > 
> > # cp /.../disks-i386/2.1.9-1999-03-03/resc1440.bin .
> > # cp resc1440.bin resc1440.bin-only-aic7xxx
> > # mount -o loop resc1440.bin-only-aic7xxx  /mnt
> > # cp vmlinuz-2.0.36-only-aic7xxx /mnt/linux 
> > # /mnt/rdev.sh 
> > + set -e
> > + readonly Arch=i386
> > + Arch=i386
> > + '[' i386 '!=' m68k ']'
> > + rdev -R /mnt/linux 1
> > + rdev -r /mnt/linux 0
> > + rdev -v /mnt/linux -1
> > + rdev /mnt/linux /dev/ram0
> > # umount /mnt
> > 
> >   available as ftp://kalle.csb.ki.se/pub/resc1440.bin-only-aic7xxx
> > 
> > To save download time, get vmlinuz-2.0.36-only-aic7xxx and do part two
> > yourself.
> > 
> > If this does not work, hmm, big problems
> > If this do work, let us include more SCSI support and iterate till we find
> > the one cousing the conflict.
> 
> --
> .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
> 

Mail 2:
On 10 Jul 1999, Adam Di Carlo wrote

> The last news I saw was that Karl H. had worked out a new kernel image
> and rescue image at
>
>    ftp://kalle.csb.ki.se/pub/vmlinuz-2.0.36-only-aic7xxx
>    ftp://kalle.csb.ki.se/pub/resc1440.bin-only-aic7xxx
>
> Can this group give me solid confirmation that these are still there,
> and work well, that is, solve a significant percentage of problems
> that people have with the current boot disks.
>
> BTW, I'm not considering *replacing* the current rescue disk with
> this, just *supplementing* it.



Reply to: