[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