Michael Kelly, le sam. 30 août 2025 11:08:40 +0100, a ecrit: > I've also had a number of occasions where the rumpdisk task was semingly the > central figure in a system wide lockup with the kernel debugger user space > stack trace showing, for example: > > thread: 32 > Continuation mach_msg_continue > >>>>> user space <<<<< > mach_msg_trap 0x822daec(0x81b2360(7b518b4,2,0,18,ae) > __pthread_block 0x81e0369(7c04320,20118840,7b518f8,8120e02,0) > __pthread_cond_timedwait_internal > 0x81e0ce4(7c04260,7c04b40,ffffffff,0,81e0e09) > pthread_cond_wait 0x81e0e21(7c04260,7c04b40,7c04b40,812c2bd,0) > rumpuser_cv_wait 0x812cadd(7c04260,7c04b40,7b519e8,811bd11,7c04b40) > 0x811bd7c(200aefa0,200aef9c,1000,1,0) > rumpns_physio 0x818a37c(806f110,0,303,0,0) > 0x8070512(303,0,7b51c64,10,1) > rumpns_cdev_write 0x80d666b(303,0,7b51c64,10,812c2a9) > rumpns_spec_write 0x8160ccb(7b51bac,8354d74,819c98b,8354d74,0) > 0x819b5ba(20092000,7b51c64,10,20048040,0) > 0x816d399(2011e0c0,7b51cd8,7b51c64,20048040,0) > rumpns_dofilewrite 0x8096a44(3,2011e0c0,71fb000,1000,7b51cd8) > 0x817d105(20118840,7b51d58,7b51d50,8124fbe,0) > 0x812500e(ae,7b51d58,18,7b51d50,0) > 0x8117dac(3,71fb000,1000,20b7b000,0) > rumpdisk_device_write 0x804a413(20013f80,b2,12,0,105bd8) > _Xdevice_write 0x804d371(7b51ee0,7b53ef0,819febb,cb87f3c,7b53ef0) > 0x804ab9b(7b51ee0,7b53ef0,7b51e94,0,7b53ef0) > 0x804e21b(7b51ee0,7b53ef0,0,0,80001712) > 0x81b26da(7b55f98,2000,10,900,1d4c0) > 0x804e34b(0,8354d74,7b55fe8,819e545,0) > 0x819e589(7c04320,cb87f78,0,0, > > The above might not be abnormal,
This looks just like normal waiting for the disk to write, indeed. Note the FIXME in block-rump.c: so far, for simplicity to get something working, we use synchronous read/write. We'd rather make this asynchronous, it'll probably be quite more efficient. Samuel
