Red Hat Bugzilla – Bug 173307
Support installation on Cell Broadband Engine
Last modified: 2008-05-06 20:17:59 EDT
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.
We'll also need anaconda to handle the /dev/bogus0 console, which is currently
using the experimental major 240
* 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
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
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
Is that a failure mode which is immediately recognisable? I'll go poke at it
some more to see what's happening....
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
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)
eating /de |
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?
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
Created attachment 121346 [details]
mambonet detection patch for kudzu
Created attachment 121347 [details]
/dev/console fallback for anaconda
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 :)
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
Where is this console.patch of which you speak?
the combination of my browser, me and possibly our firewall seems te unable to
create an attachment. I there another way? email?
Email to firstname.lastname@example.org is always the best way to get it included :)
But mailing it to me would be useful in the meantime; yes.
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.
Created attachment 121684 [details]
Created attachment 122027 [details]
kudzu patch to detect mambo block device
This should make the virtual block device get detected.
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,
kudzu patches applied in 1.2.14-1.
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
SystemError: (2, 'No such file or directory')
User email@example.com's account has been closed
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.
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: