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

Re: Booting installer on RS/6000 43p-140



On Sun, Jul 18, 2004 at 09:28:15AM +0100, Leigh Brown wrote:
> Sven Luther said:
> > On Sun, Jul 18, 2004 at 09:09:49AM +0100, Leigh Brown wrote:
> >> Sven Luther said:
> >> > On Tue, Jul 13, 2004 at 10:56:23AM +0100, Leigh Brown wrote:
> >> >> Sven Luther said:
> >> >> > Could you please try netbooting
> >> >> >   http://people.debian.org/~luther/debian-installer/daily-powerpc-built/2004-07-13/powerpc/netboot/2.6/vmlinuz-prep.initrd
> >> >> >
> >> >> > With the console=ttyS0 option or whatever, and send me the serial
> >> >> > log?
> >> >>
> >> >> Hi Sven.  I thought I'd give that kernel a try.  I don't netboot, put
> >> >> I wrote that kernel to my second harddisk and booted from it.  In
> >> >> summary, it boots, but it doesn't seem to include the pcnet32 driver.
> >> >> Since every single RS6000 "offical" ethernet card that I've ever seen
> >> >> uses pcnet32, I'd say its important to include it in the initrd.
> >> >
> >> > Ok, mmm, you mean the pcnet32 driver is not in the debian-installer
> >> net
> >> > drivers ?
> >> >
> >> > It is in the nic-extra-modules, which is not part of the initrd, we
> >> > will fix this, either move it to nic-modules or add the
> >> > nic-extra-modules to the initrd.
> >> >
> >> > Thanks for testing. Could you try again tomorrow or later ?
> >>
> >> Just to let you know I tried your latest 2.6 vmlinuz-prep.initrd kernel
> >> and this time the installer detected my ethernet card just fine.  This
> >> time it got to the partitioner without loading a SCSI driver.  I might
> >> be a bit dim but I couldn't work out how to download the additional
> >> kernel modules for that.
> >
> > Could you send us a lscpi and lspci -n output on that box ? What scsi
> > card do you have ?
> 
> It's my 140.  I've attached the lspci output at the end.  However, every
> PReP box I have has an onboard Symbios 53c8xx SCSI controller compatible
> with the sym53c8xx v2 driver.  That driver probably covers 99% (if not
> 100%, but I'm not sure) of all RS/6000 PReP boxes.  Even my Motorola
> Powerstack has a sym53c8xx controller.
> 
> 00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 30)
> 00:00.0 Class 0600: 1057:0002 (rev 30)
>         Flags: bus master, fast devsel, latency 0
> 
> 00:0b.0 ISA bridge: IBM Fire Coral (rev 03)
> 00:0b.0 Class 0601: 1014:000a (rev 03)
>         Flags: bus master, slow devsel, latency 0
>         I/O ports at 1000 [size=8]
> 
> 00:0c.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32
> LANCE] (rev 16)
> 00:0c.0 Class 0200: 1022:2000 (rev 16)
>         Flags: bus master, medium devsel, latency 32, IRQ 22
>         I/O ports at 1020 [size=32]
>         Memory at fad9d000 (32-bit, non-prefetchable) [size=32]
>         Expansion ROM at fada0000 [disabled] [size=64K]
> 
> 00:0d.0 Class ff00: IBM MPIC interrupt controller
> 00:0d.0 Class ff00: 1014:0046
>         Flags: medium devsel
>         Memory at fadc0000 (32-bit, non-prefetchable) [size=256K]
> 
> 00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c825 (rev 13)
> 00:10.0 Class 0100: 1000:0003 (rev 13)
>         Flags: bus master, medium devsel, latency 32, IRQ 23
>         I/O ports at 1400 [size=256]
>         Memory at fad9e000 (32-bit, non-prefetchable) [size=256]
>         Memory at fad9f000 (32-bit, non-prefetchable) [size=4K]

This is : 

        10000003        scsi    ncr53c8xx       53c825

in discover's pci.lst. Was this detected correctly with the 2.4 kernel
and discover 1 ?

And discover2 has :

  <device busclass='0000' model='0003' vendor='1000' model_name='53c825'>
    <data class='linux'>
      <data version='[2.6,inf)' class='module'>
        <data class='name'>sym53c8xx</data>
      </data>
      <data version='[2.2,2.6)' class='module'>
        <data class='name'>ncr53c8xx</data>
      </data>
      <data class='last-updated'>2004-04-26</data>
      <data class='last-updated-by'>imurdock@progeny.com</data>
    </data>
  </device>

So, this means that for 2.4, ncr53c8xx gets loaded, and for 2.6 and
discover2, sym53c8xx gets loaded, while 2.6 and discover1 gets loaded.

We are still using discover1 for all initrd, which cause this kind of
problems, more to this later on.

BTW, i wonder if adding symlinks from the older 2.4 names to the newer
2.6 names in the 2.6 initrd, maybe a hacky workaround to the discover1
problem.

Also, what would be the possibility to have two pciids files, one for
2.4 and the other for 2.6, and have discover test the kernel version
before choosing ? 

Could you fill a installation report bug against debian-installer with
this info please ? 

Friendly,

Sven Luther



Reply to: