Re: Where to run the Hurd

[Sergiu Ivanov]

Hello,

On Sat, Jun 27, 2009 at 10:11:37PM +0200, Samuel Thibault wrote:
> Sergiu Ivanov, le Sat 27 Jun 2009 23:00:43 +0300, a écrit :
> > On Sat, Jun 27, 2009 at 09:32:53PM +0200, Samuel Thibault wrote:
> > > Sergiu Ivanov, le Sat 27 Jun 2009 22:24:58 +0300, a écrit :
> > > > Probing PCI hardware.
> > > > 
> > > > Here it stops. Is this good or bad? :-)
> > > 
> > > I've never seen that. You could track down by putting printfs. (That's
> > > what I did for fixing a couple of bugs).
> > 
> > Where do I put printfs? Do you mean that I'll have to modify something
> > the source of GNU Mach?
> 
> Yes. rgrep "Probing PCI hardware" to find out where you can start adding
> printfs from.

I used printk for dumping debug messages, since I had seen calls to it
immediately as I opened the first GNU Mach source file. I hope this is
not too bad...

So, I did a somewhat long expedition and found out the following:

``Probing PCI hardware'' is dumped from pci_init, invoked from
linux_init. The problem does not, however, appear in pci_init
itself. I traced the following chain:

linux_init->device_setup (from linux/dev/drivers/block/genhd.c)->
blk_dev_init->ide_init->probe_for_hwifs->ide_probe_promise_20246.

I hope this notation makes it clear that I'm talking of something
similar to a backtrace.

ide_probe_promise_20246 is a three-line function (I hope I remember
well) which invokes a generic function for searching PCI devices
which, apparently, hangs. I didn't try to dive deeper, because

1. ide_probe_promise_20246 invokes a function pointed to by a
   pointer-to-function field in a structure, which meant that I should
   start a series of (rather obscure) greps and test boots to first
   find out what that field points to at the moment
   ide_probe_promise_20246 is invoked.

2. The results I have *already* show that my position WRT this problem
   is not far from being true (more on this below).

3. Anyways, nobody is going to fix this, since (a) I do not have the
   knowledge (and the time, BTW) yet to endeavour at this task and (b)
   those who *do* have the knowledge and the time will most probably
   devote their efforts to something more important than looking at
   support of Promise Technology in Mach.

My position (which I think I've exposed shortly in the beginning of
this discussion) is that Mach cannot see my hard drives because of the
(exotic) software RAID feature on the motherboard which I cannot
disable. It is called Promise Fasttrak (about which I see nothing on
Wikipedia even) and it was experimental back in 2000 when I bought my
old box. Also, SUSE 10 refused to install, telling me that the support
for such drives had been removed from the system, being not the only
OS reluctant to run in such configuration.

The fact that things hang right in the function which tries to probe
for some Promise controllers may have two reasons:

1. The controller put on my motherboard is so old (or so experimental)
   that it never became mainstream enough to be included in
   Mach. Also, I saw there are several (different) versions of this
   Promise stuff, while Mach probes for only one of these (the oldest,
   it looks to me). (I derived this data from here:
   http://www.dslreports.com/forum/r22145194-IDE-controller-card).

2. Something in the way how Mach probes for this very type of
   controller is erroneous, this being the reason for hanging.

I thought it wasn't worth the time to try to find out which reason
exactly is the real one, so I stopped my exploration here.

I hope I've provided a few relevant pieces of information.

Regards,
scolobb