<AlmuHS>I've just installed Debian GNU/Hurd in my Thinkpad T410. It goes very fine, and the network card is working successfully <AlmuHS>very good improve since 2017 version. Debian GNU/Hurd 2017 didn't detect my network card. The latest version yes ***Server sets mode: +nt
***Out`Of`Control is now known as Viper
***jma is now known as junlingm
<damo22>youpi: in trivfs_S_fsys_init (struct trivfs_control *fsys, ... is that where i set fsys->underlying before calling fsys_getroot ? <damo22>i tried creating a port on trivfs_cntl_class and giving it a send right to fsys->underlying <damo22>or do i just give it the initial bootstrap port? <youpi>damo22: it seems you didn't understand what "underlying port" means here <youpi>see what normally happens when mounting a translator <youpi>the translator starts, the caller gets a control port on it <youpi>it calls getroot on it, to get a port to the / of the FS <youpi>but also the translator needs to know what the node it's mounted on looks like (uid, gid, perms) <youpi>so is given a port to the underlying node <youpi>the node on which it's mounted <youpi>so here it's the node you got when looking up /dev/rumpdisk <youpi>so that's only when you actually have the port to give trivfs to <damo22>so at what point is the earliest i can have a port to /dev/rumpdisk? <youpi>see what I had written in the bootstrap page <youpi>TODO: we want diskfs_startup_diskfs to also call task_get_bootstrap_port to call fsys_startup on its real bootstrap port once diskfs_start_bootstrap is finished, for bootstrap translators before the root filesystem to know when the root filesystem is ready, and register themselves as translators in the root filesystem, register for shutdown notification, etc. <damo22>but fsys_startup is called before fsys_init <damo22>because it passes the control port so i can save it <youpi>well, with the control port you should already be able to call fsys_getroot? <youpi>really I don't know all of this by heart <youpi>I'm just reading the source code <youpi>possibly you have to wait for fsys_init as well, I don't really know <youpi>really, all I know just comes from reading the source code in the normal translator path <damo22>im pretty sure i fixed that TODO <damo22>im just confused what port to pass as underlying <youpi>that's what I wrote above yes <youpi>(11:18:57) Samuel Thibault: so here it's the node you got when looking up /dev/rumpdisk <AlmuHS>good news: my SMP patch works in Thinkpad T410. This model has an i5 processor, which theorically doesn't works with xAPIC. But, at moment, my patch is able to detect all cores of the processor <AlmuHS>it's possible that, in next step, the cpu enabling will fails, because the IPI are different in x2APIC than xAPIC. But this first step works well <AlmuHS>added to this, in this model I have not any problem with tty. The tty doesn't freeze, even with mouse <AlmuHS>but, by the contrary, the ACPI translator crash during the shutdown <AlmuHS>being a Hurd betatester over real hardware is funny :-) <AlmuHS>curiosity: why my patch detect the logical cores together the physical cores? In this i5 dual core, my code shows 4 cores (two of them are logical, not physical) <youpi>AlmuHS: that's not surprising. from the software point of view, logical cores are appearing as complete processors <AlmuHS>I've just tried my old SMP version, enabling the processors. In fact, the enabling fails in this machine (i5 use x2APIC, which manage the IPI in a different way) <AlmuHS>when the IPI is sent, the machine reboots <AlmuHS>youpi: but... the logical processor also might be enabled using IPI? <AlmuHS>or the logical processor is enabled together its physical processor? <AlmuHS>in my design, I don't check if the processor is physical or logical <youpi>from the software point of view, logical processors are just normal processors <youpi>you *don't* have to care whether its a thread, a core, a socket, whatever <AlmuHS>ok, then I simply send IPI to all processors: logical and physical <AlmuHS>then, the only problem will be to force Core i processors to using xAPIC, instead x2APIC <AlmuHS>but this is a difficult task, it's not trivial, so I prefer to set a TODO for future versions <AlmuHS>I've just tested my old SMP microkernel, adding latest commit from upstream, in the Thinkpad T60. As in default's upstream, now I have network connection without debian patches. But, as expected, the tty continues freezed (It might be a IOAPIC problem) <AlmuHS>the old SMP microkernel enable and integrate the cpus in the kernel, but doesn't implements IOAPIC <AlmuHS>once checked It, I can continue my current SMP work, refactoring and improving the code <AlmuHS>in a days i will send my patch, fixing the issues which you told me in the maillist 
