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: unlimitedscolobb
Subject: Re: Where to run the Hurd
Date: Sat, 18 Jul 2009 01:06:39 +0300
User-agent: Mutt/1.5.18 (2008-05-17)

Hello,

I'm sorry for this very late reply :-( It turned out that I was
busier than I considered myself to be :-(

On Thu, Jul 02, 2009 at 08:51:11PM +0200, Samuel Thibault wrote:
> Thanks for your investigation, it's clearly useful!

I actually enjoy doing this.  It has been my dream for a long time to
go down to the kernel level, so it's very exciting for me to actually
do something to the kernel itself (although it's only adding printk's
so far :-) ).
 
> Sergiu Ivanov, le Mon 29 Jun 2009 16:31:19 +0300, a écrit :
> > 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.
> 
> The serial number doesn't exactly match, so there is little surprise I
> guess.

Yep, this is a clear matter.
 
> > ide_probe_for_cmd640x hangs in the call to probe_for_cmd640_pci1.
> 
> Ok. That's odd as there is no infinite loop there :)
> 
> > 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
> 
> Oh? That's not supposed to happen, as the code shows as well as callers
> of these. Could you investigate in that direction?

No, surely ide_probe_for_cmd640x calls probe_for_cmd640_pci1 only
once.  I'm sorry :-( Unfourtunately, I'm mostly studying the matter at
odd times, which results in attention bugs :-(
 
> > In the first calls match_pci_cmd640_device gets called
> > only once per call to probe_for_cmd640_pci1.
> 
> That's odd too, could you check the value returned by
> match_pci_cmd640_device and the value of cmd640_key?

My replica about match_pci_cmd640_device being called once per call
is, obviously, rubbish.

Also, I have noticed another ``attention bug'': gnumach hangs in
probe_for_cmd640_pci2.  cmd640_key in this function goes from 0xC000
up to 0xCC00 and match_pci_cmd640_device hangs there.  At all times
the i-loop inside the match_pci_cmd640_device function does not go
beyond i = 0.  The function get_cmd640_reg_pci2 hangs when cmd640_key
is 0xCC00 at the line ``b = inb_p(cmd640_key + reg);'' (sorry, I don't
give line numbers, because mine are distorted by debug printk's).

I very much hope I will not find any big mistakes in this description
when I will look at it next time...

> > Other from FDC, nothing looks like a hard drive here.
> 
> Indeed. I guess your controler is a SATA one. You need to enable legacy
> IDE/ATA emulation in the bios for gnumach to be able to use it. If there
> is no such option, you're hosed :/

Well, I don't think my controller is a SATA one :-) The reasoning is
simple: Wikipedia tells that SATA was created in 2003, and I bought my
old box in 2001 :-)

Unfourtunately, I have nothing similar to IDE/ATA emulation in my BIOS
:-(

Great thanks for your helpfulness! :-)

Regards,
scolobb




reply via email to

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