Hello, On Sun, Jun 28, 2009 at 10:40:14PM +0200, Samuel Thibault wrote: > Sergiu Ivanov, le Sun 28 Jun 2009 23:17:11 +0300, a écrit : > > linux_init->device_setup (from linux/dev/drivers/block/genhd.c)-> > > blk_dev_init->ide_init->probe_for_hwifs->ide_probe_promise_20246.
I'm sorry: yesterday in the evening I was somewhat tired, that's why I mistook the results from the debug output. Mach hangs not *in* the call to ide_probe_promise_20246, but *after* this call, in ide_probe_for_cmd640x. Since ide_probe_promise_20246 prints a message in case it detects what it probes for and nothing gets printed to my screen, I guess that Mach does not detect my Promise drives anyway. ide_probe_for_cmd640x hangs in the call to probe_for_cmd640_pci1. This latter function calls match_pci_cmd640_device in a loop and what my output tells me is that ide_probe_for_cmd640x calls probe_for_cmd640_pci1 several times (> 5, the beginning went away from my screen). In the first calls match_pci_cmd640_device gets called only once per call to probe_for_cmd640_pci1. However, at a definite moment, the loop inside probe_for_cmd640_pci1 calls match_pci_cmd640_device several times (~15) and the last of these calls hangs. Shall I print out some more details to tell the values of variables? > What does lspci tell you about your promise controller? I do lspci | grep -i promise and get the following (line broken by MUA): 00:0c.0 RAID bus controller: Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100) (rev 02) > You can try to comment the call to ide_probe_promise_20246() to > check what it does. Since ide_probe_promise_20246 isn't obviously the point where problems appear, I decided to comment the call to ide_probe_for_cmd640x. After this Mach gave me the following: , <0x100000:0x19c0b4:0x0>, <0x29d00:0xe3ac:0x25c48>, shtab=0x2d12f8Starting up ... GNU Mach 1.3.99 AT386 boot: physical memory from 0x0 to 0x1fff0000 pcibios_init : BIOS32 Service Directory structure at 0xfdb20 pcibios_init : BIOS32 Service Directory entry at 0xfdb30 pcibios_init : PCI BIOS revision 2.10 entry at 0xfdb51 Probing PCI hardware. hd0: HL-DT-ST DVDRAM GSA-H42N, ATAPI CDROM drive hd1: SONY CD-RW CRX140E, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 or irq 14 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Other from FDC, nothing looks like a hard drive here. Also, one of the meanings of this acronym (Wikipedia) seems to be Floppy Disk Controller. > Could you paste the precise line you are seeing the hang in (even if > it's a call to some generic function)? Is your request relevant now? Would you need an excerpt of the code I have? Probably, is should be better that I get the code you have, since my version must be outdated (see below). > It seems we do not have the same source code. I get the code by $ cvs -z3 -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach According to http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html. I know that there is a git gnumach repository, but Thomas told me that the disk detection stuff hadn't changed for a long time, so it shouldn't matter that I get the code from CVS. Regards, scolobb
