Re: rumpdisk device timeouts

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