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
