Gregory Haerr

> panic: Process -31913 exceeded kernel stack limit! magic c483 This message could mean old-fashioned kernel stack overflow. Lets increase the kernel stack size, just in case the SX system...

> (btw truncate is called from only one place in the code and '__u32 i_size' is always 0, so the DIRECT_BLOCK macro is superfluous for now). Yes, inode->i_size is set...

> I didn't realize that schedule() would switch stacks in a case like this, thanks - that's very useful. It may not switch stacks, depends on what else is running....

Hello @Mellvik, can you (re)post the QEMU screenshot showing the associated error? > Now, here's the thing with the DIRECT_BLOCK macro: > However, in V1_trunc_direct() it's being used twice as...

Hello @Mellvik, I have duplicated the QEMU-staged "mnb: still zero bit!8192" bug on my system. I'm not sure if this is a relic of just having run out of disk...

With regards to the "new" bug, lets call it "out of disk space" bug: > Also I agree it's likely a separate issue, it would be interesting to see if...

Hello @Mellvik, Wow, you really have made some progress on this!! I'm interested in how you were able to pinpoint the memory locations that are being overwritten? I'd like to...

With regards to the origin of the memory corruption: ``` elks17# hd d0:16238#4.

> was bioshd.c and how it probes drives, in order to see if the BIOS returns odd values for the DiskOnChip which the system supports. You may be on to...

Hello @Mellvik, Hello @tkchia, I agree with all of @tkchia's suggestions, they are very good ideas. I think we can get to the bottom of this, but I want to...