Kcore: Page Fault: while compiling Haiku on a Haiku

[apn4m3rdrock]

System: Dell 1100 inspiron 256MB Mem, 1GB VMem Haiku Build: hrev32063-gcc4 Attached: Photos of the error

I was able to easily reproduce this error 5-6 times. Every time I start jam -q haiku-image, within seconds kernel dumps core.

Steps:

1. Copied Haiku Raw Image on a partition of 700MB
2. Rebooted, and Installed (thru Installer) installed on a partition of 3.4GB
3. Rebooted and Adjusted Vmem to 1GB
4. Rebooted once again and started compilation process
   1. Source files on a third BEOS partition of 5GB
   2. ./configure
   3. jam -q haiku-image
   4. messages "..patience.." pops up around some 10 times before it

dumps core (pagefault).

[apn4m3rdrock]

'Sorry, it seems to be a buggy driver for broadcom 440x driver, didn't notice the last 3 lines of the kdebug message (Needs conformation though !!!)

[axeld]

Definitely, anyway that should be helpful.

[mmlr]

Quickly looking at it it would be my guess that the allocation of the mbuf fails due to low memory. Since the driver doesn't really care to check allocations it crashes.

[umccullough]

At least on my Dell Inspiron 1100 with 1gb RAM I haven't run into issues with that driver yet, but that's likely because I haven't hit the ceiling :)

Also, it's been a long time since I've tried to compile Haiku on it, probably time to test that again I suppose.

[axeld]

In FreeBSD, kernel allocations obviously cannot fail. I'm not sure how they achieve this (probably by killing apps in the worst case), but it's obvious that this is not yet done in Haiku.

Eventually, the FreeBSD compatibility layer would need to allocate some memory upfront for the mbufs to make sure they don't easily run out.

[jonas.kirilla]

Replying to axeld:

Eventually, the FreeBSD compatibility layer would need to allocate some memory upfront for the mbufs to make sure they don't easily run out.

I don't know if it's possible with the compatibility layer (or perhaps already done), but some kind of interrupt mitigation would help a loaded system from receiving traffic it can't handle, limiting/dropping traffic before it enters the system and resources are wasted on it. It doesn't do any good for failed allocations, but it should help overall.

OpenBSD are looking at live shrinking a NIC's ring buffer based on how well mbufs reach userspace. (I hope I got that right.) I think Linux switches from interrupts to polling a NIC, beyond a certain threshold.

[jonas.kirilla]

Here's a presentation on how OpenBSD does what I mentioned above.
​http://au.sun.com/sunnews/events/2009/kernel/d/KCA3_Gwynne_MCLGETI.pdf
(slide 38 and forward)

[waddlesplash]

Changes to object_cache behavior may have fixed this. Please retest.

[waddlesplash]

Fixed (again) in hrev52653, as mmu_man fixed it some years ago first in ​https://github.com/haiku/haiku/commit/cad8f65d222396aa33e00673bf3d03fb315edb0a.

In FreeBSD, kernel allocations obviously cannot fail. I'm not sure how they achieve this (probably by killing apps in the worst case), but it's obvious that this is not yet done in Haiku.

They absolutely can fail except when passed the "use reserve memory flag," which is not done anywhere here, and what's more it specifically passes M_NOWAIT which indicates that it shouldn't spend any extra time creating a new buffer if one isn't immediately available.

FreeBSD fixed the bug (though not in time for 11.0) in ​https://github.com/freebsd/freebsd/commit/e25a5b6a7c7e0ee0bca364c3888265e953c03bb8.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone