Opened 10 years ago

Closed 7 months ago

#4293 closed bug (fixed)

Kcore: Page Fault: while compiling Haiku on a Haiku

Reported by: apn4m3rdrock Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Network/broadcom440x Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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).

Attachments (2)

100_2607.jpg (184.9 KB) - added by apn4m3rdrock 10 years ago.
100_2608.jpg (193.3 KB) - added by apn4m3rdrock 10 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by apn4m3rdrock

Attachment: 100_2607.jpg added

Changed 10 years ago by apn4m3rdrock

Attachment: 100_2608.jpg added

comment:1 Changed 10 years ago by 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 !!!)

comment:2 Changed 10 years ago by axeld

Component: System/KernelDrivers/Network

Definitely, anyway that should be helpful.

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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.

comment:6 in reply to:  5 ; Changed 10 years ago by 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.

comment:7 in reply to:  6 Changed 10 years ago by 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)

comment:8 Changed 7 years ago by diver

Component: Drivers/NetworkDrivers/Network/broadcom440x

comment:9 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned

comment:10 Changed 9 months ago by waddlesplash

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

comment:11 Changed 7 months ago by waddlesplash

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.