bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]