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.