Bug 173307 - Support installation on Cell Broadband Engine
Summary: Support installation on Cell Broadband Engine
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Mike McLean
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-16 08:02 UTC by David Woodhouse
Modified: 2008-05-07 00:17 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2008-05-07 00:17:59 UTC

Attachments (Terms of Use)
mambonet detection patch for kudzu (598 bytes, patch)
2005-11-22 13:44 UTC, David Woodhouse
no flags Details | Diff
/dev/console fallback for anaconda (984 bytes, patch)
2005-11-22 13:46 UTC, David Woodhouse
no flags Details | Diff
console patch (2.28 KB, patch)
2005-12-01 13:51 UTC, David Woodhouse
no flags Details | Diff
kudzu patch to detect mambo block device (973 bytes, patch)
2005-12-08 13:28 UTC, David Woodhouse
no flags Details | Diff

Description David Woodhouse 2005-11-16 08:02:30 UTC
there's HOWTO describing various changes required to install FC4 on Cell. Of
those, some would be useful to get into FC5. Specifically: 

 - the addition of spidernet to the NETMODULES in mk-images.ppc.

 - I'd also like to add 'mambonet', which is the virtual Ethernet in the
simulator. I think that will require kudzu patches to 'detect' it too, since
otherwise I seem to recall that anaconda won't be able to use it even after the
module is loaded and the 'eth0' device is actually present. Is that still the case?

 - some handling of the 'BPA' machine type so that they don't have to hack the
kernel to report CHRP instead.

 - perhaps also recognising that 'bogus0' and 'rtas0' are virtual serial console
s and need treating as such when creating inittab, as we do for hvc0.

- setting 'nonvram' in yaboot.conf for now, I think.

Comment 1 David Woodhouse 2005-11-21 14:23:16 UTC
We'll also need anaconda to handle the /dev/bogus0 console, which is currently
using the experimental major 240

Comment 2 Jeremy Katz 2005-11-21 20:30:17 UTC
* Adding modules to the initrd is easy, we'll do that
* How does mambonet show up?  Yes, there has to be a way to detect that the
driver is needed (to load it) and then that there are devices (so that we ensure
the device has support loaded)
* Machine type handling can be done, what does it need to affect?  Also, what's
the thing to key off of (the handling is in iutil.py:getPPCMachine so it should
be obvious enough)
* The serial stuff will need to have a major before we can really do much with
them.  Also, isn't this getting a bit out of control on the number of these
things? :P

Comment 3 David Woodhouse 2005-11-21 20:59:33 UTC
1. Thanks.

2. The existence of mambonet is indicated by the existence of /mambo/bogusnet@0
in the device-tree. 

3. I think the machine type handling is obsolete -- the upstream kernel now
claims to be CHRP so that's OK.

4. Yeah, that's why I updated it to note that it's currently using an
experimental device number. Is there any way we could make this more generic by
using /dev/console?

I hacked the kernel to make bogusconsole appear as /dev/hvc0. Now I see this...

  anaconda installer init version 10.90.5 starting
  mounting /proc filesystem... done
  creating /dev filesystem... done
  mounting /dev/pts (unix98 pty) filesystem... done
  mounting /sys filesystem... done
  anaconda installer init version 10.90.5 using /dev/hvc0 as console
  could not set new controlling tty
  trying to remount root filesystem read write... done
  mounting /tmp as ramfs... done
  running install...
  running /sbin/loader

Is that a failure mode which is immediately recognisable? I'll go poke at it
some more to see what's happening....

Comment 4 Jeremy Katz 2005-11-21 21:11:26 UTC
We used to do generic things with /dev/console, but there are things which
/dev/console supports which you can't do with the various pseudo consoles like
hvc, etc.  Nothing immediately springs to mind with the error you're getting --
it's that TIOCSCTTY is failing but I don't know why you wouldn't then get the
output from the loader

Comment 5 David Woodhouse 2005-11-22 08:16:45 UTC
Still, couldn't we fall back to /dev/console if nothing else works? 

Turns out /sbin/loader _was_ running OK... sort of. The screen rendering is
somewhat lacking -- when first displaying a screen it seems to display none of
it, but then when I tab and move around, the updates to seem to get rendered.
Here's an example after I scroll down through the network driver selection...

IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 6, 262144 bytes)
TCP bind hash table entries: 8192 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
   | Apple Airport (airport)                                              # |   
   | Apple GMAC (sungem)                                                  # |   
   | Asix AX88190 PCMCIA ethernet driver (axnet_cs)                       # |   
   | Atmel at76c50x 802.11 PCMCIA wireless ethernet (atmel_cs)            # |   
   | Atmel at76c50x 802.11 wireless ethernet (atmel_pci)                  # |   
anacoBroadcom 4400 10/100 PCI ethernet adapter (b44)                    
mounting /pr                                                                   
  eating /de                                                           |   
mounting /de                                                         
mounting /sy                                                         
anaconda ins         OK                                Back          
could not se            |                                            
trying to remount roo                                      
mounting /tmp as ramf |                                    
  <Tab>/<Alt-Tab> between elements  | <Space> selects | <F12> next screen

Ever seen that one before?

How does the 'telnet' option work? Do you have to give it the ip= option to
avoid having to interact on the console?

Comment 6 David Woodhouse 2005-11-22 13:43:48 UTC
T'was a console driver bug. I've got it working now... slowly.

I've added a 'console' boot argument to anaconda to make it use /dev/console
rather than needing specific knowledge about every possible type of console.
I've also taught kudzu about mambonet (as well as pjones' patch to add it to
anaconda's module-info)

Comment 7 David Woodhouse 2005-11-22 13:45:00 UTC
Created attachment 121346 [details]
mambonet detection patch for kudzu

Comment 8 David Woodhouse 2005-11-22 13:46:29 UTC
Created attachment 121347 [details]
/dev/console fallback for anaconda

Comment 9 David Woodhouse 2005-11-22 14:47:58 UTC
Ok, that's an improvement. Now I get as far as mounting NFS before it says 'No
hard drives have been found'. I suppose I need to teach it about mambobd now :)

Comment 10 Gerhard Stenzel 2005-12-01 13:27:19 UTC
I implemented a workaround to allow the coexistence of the rtascons patch with  
hvc_console and verified that it boots on CBE hardware. I did not verify it on  
pSeries hardware. The details are in console.patch  

Comment 11 David Woodhouse 2005-12-01 13:30:28 UTC
Where is this console.patch of which you speak? 

Comment 12 Gerhard Stenzel 2005-12-01 13:36:52 UTC
the combination of my browser, me and possibly our firewall seems te unable to 
create an attachment. I there another way? email? 

Comment 13 David Woodhouse 2005-12-01 13:41:30 UTC
Email to torvalds@osdl.org is always the best way to get it included :)

But mailing it to me would be useful in the meantime; yes.

Comment 14 Gerhard Stenzel 2005-12-01 13:48:02 UTC
Regarding your first suggestion: We are looking into a solution which will 
integrate better with hvc_console, similiar to hvc_vio and this will go this 
route .. in the meantime there is this workaround, which I just sent you. 

Comment 15 David Woodhouse 2005-12-01 13:51:49 UTC
Created attachment 121684 [details]
console patch

Comment 16 David Woodhouse 2005-12-08 13:28:07 UTC
Created attachment 122027 [details]
kudzu patch to detect mambo block device

This should make the virtual block device get detected.

Comment 17 David Woodhouse 2005-12-08 13:31:08 UTC
We've got an rtas console patch which plugs into the generic hvc console code
now, so the console patch and the anaconda patch to fall back to /dev/console
can be dropped (although the anaconda patch might be useful in other
circumstances -- it's better to fall back to /dev/console than just do nothing,

Comment 18 Bill Nottingham 2005-12-09 19:56:51 UTC
kudzu patches applied in 1.2.14-1.

Comment 19 David Woodhouse 2005-12-11 17:54:05 UTC
Thanks. Now I see this in the sim... did I do something wrong?

Traceback (most recent call last):                                              
  File "/usr/bin/anaconda", line 1077, in ?                                     
  File "/usr/lib/anaconda/iutil.py", line 464, in makeDriveDeviceNodes          
    isys.makeDevInode(drive, "/dev/%s" % (drive,))                              
  File "/usr/lib/anaconda/isys.py", line 415, in makeDevInode                   
    _isys.mkdevinode(name, fn)                                                  
SystemError: (2, 'No such file or directory')       

Comment 20 Red Hat Bugzilla 2007-08-21 05:21:11 UTC
User pnasrat@redhat.com's account has been closed

Comment 21 Bug Zapper 2008-04-03 16:37:58 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 22 Bug Zapper 2008-05-07 00:17:57 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

Note You need to log in before you can comment on or make changes to this bug.