[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hurd rumpdisk on real hardware



Hi João,

On Mon, Sep 08, 2025 at 08:54:44PM +0100, Michael Kelly wrote:
I built an ext2fs disk image of hurd-i386 using mmdebstrap which when dd'd
onto a partition using Qemu works normally.  The same image on the netbook
gets as far as reporting the disk geometry and capabilities correctly but
the boot log reports nothing further. Running a gnumach compiled with
--disable-linux-groups (is this valid on i386?) results in further progress
but only to report a number of lost interrupts of the form:

piixide0:0:0 interrupt lost

[.....] type ata tc_bcount: 4096 tc_skip: 0
In this a particular case, it seems that I failed a golden rule in computing generally to "never make assumptions". I had spent some time on another 64 bit system whose difficulties do indeed seem to be hardware related (Note "seem to" being a get out clause!) and then this 32 bit machine also reporting errors including interrupts led me to believe hardware issues were the cause. In actual fact, restoring the official gnumach image and looking properly I could see that the problem was nothing to do with specific hardware but just the total RAM available being 1Gb. I'll report on this issue separately to avoid polluting this thread.
I'm not hoping for a specific fix to my particular problem especially with
so little information presented. I was wondering rather if there were any
general tips, tricks or guidance to assist me to work it out for myself.
I echo your question: how to debug rumpdisk on real hardware?
I presume it is not possible to run something like a subhurd with rumpdisk on a
system using gnumach ide to already drive the disk?

I was getting a little lost in where the responsibilities lie for handling interrupts and how the rumplib kernel interfaced to Hurd. I've subsequently discovered the pci-userspace code which helped a little but it's rather the big picture that I'm missing to set the pieces of software into context. I find debugging gnumach generally quite difficult. The continuation mechanism seems to lose much of the context once a thread is blocked. That said, I've very little experience of driver code, so it might be just a difficult task all together.

Best regards,

Mike.


Reply to: