[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where to run the Hurd
From: |
Sergiu Ivanov |
Subject: |
Re: Where to run the Hurd |
Date: |
Mon, 29 Jun 2009 16:31:19 +0300 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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:anonymous@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
- Re: Setting up eth-multiplexer in QEMU, (continued)
- Re: Where to run the Hurd, Thomas Schwinge, 2009/06/27
- Re: Where to run the Hurd, Sergiu Ivanov, 2009/06/27
- Re: Where to run the Hurd, Sergiu Ivanov, 2009/06/27
- Re: Where to run the Hurd, Samuel Thibault, 2009/06/27
- Re: Where to run the Hurd, Sergiu Ivanov, 2009/06/27
- Re: Where to run the Hurd, Samuel Thibault, 2009/06/27
- Re: Where to run the Hurd, Sergiu Ivanov, 2009/06/28
- Re: Where to run the Hurd, Samuel Thibault, 2009/06/28
- Re: Where to run the Hurd,
Sergiu Ivanov <=