Trap 18 in "top"

Alright so I am new to freebsd. I was going through the handbook and I typed the "top" command and suddenly my freeBSD crashed Im a newbie so I don't know what's happening can someone explain? Is there any solution?
My lap top is Fujitsu lifebook AH530(I don't have any other option yet!)
Thanks
 
Could be anything. Analyse the crash.
I.e. or the kernel dump or application core file.
The handbook normally should explain how to do so.
 
Well analyzing system crash is really not something a new user should or most likely wants to do.

First thing I'd try is to check if the top command was actually trigger of the crash, i.e. if you can reproduce it. Try to run the command once or twice to see if you can trigger the crash.
Is this a default FreeBSD installation? Do you see any files under /var/crash?

Where did you read the "trap 18"? That's MC error (machine check), possibly HW related issues (RAM, bus, CPU..).
 
OP
RNH

RNH

Thanks I will check and report the result

And sorry I forgot the screenshots here they are
 

Attachments

  • CamScanner 07-30-2022 13.07_1 (1).jpg
    CamScanner 07-30-2022 13.07_1 (1).jpg
    245.1 KB · Views: 38
  • CamScanner 07-30-2022 13.07_2.jpg
    CamScanner 07-30-2022 13.07_2.jpg
    237.8 KB · Views: 41
OP
RNH

RNH

Well analyzing system crash is really not something a new user should or most likely wants to do.

First thing I'd try is to check if the top command was actually trigger of the crash, i.e. if you can reproduce it. Try to run the command once or twice to see if you can trigger the crash.
Is this a default FreeBSD installation? Do you see any files under /var/crash?

Where did you read the "trap 18"? That's MC error (machine check), possibly HW related issues (RAM, bus, CPU..).
Yes I think it's "top" because it happens everytime I execute the command.

Yes I used the default installation but without debugging tools or anything.

I checked /var/crash and there was info.last which didn't give me anything useful. And there were core.txt files Wich said I don't have gdb debugger.

I think I should leave it until I've read the handbook further and then I should maybe try again.

Thank you guys.
 
Please disregard my info about MC error.
The kernel is crashing in function acpi_battery_sysctl() as indicated in the trap info due to division error. You won't fix this by reading handbook (but you should use handbook to get yourself familiar with the FreeBSD).

You can/should open a problem report (PR) to let the developers know. Please do check the howto on that page to get familiar with the process.
Before that make sure that:
1) you are using GENERIC kernel (which you confirmed you are using default installation)
2) you have up-to-date FreeBSD running (so either 12.3, 13.0, 13.1)
3) you have dump available (vmcore.N in /var/crash, maybe zipped ; N is the number starting from 0)

When you open a PR you can share the information about the system (hw details, FreeBSD details), possibly pictures of the dump you have a the actual dump file.

In the dump pictures you shared I see dump completed so if you have enough free space in /var/crash you should see a proper dump there. You don't need debugging tools for this.
The only other PR opened for this topic was back in 2009 - PR 122056
 
A good question you can ask yourself is what information do you need to provide to your neighbor to reproduce the problem in a simple way.
Does the problem occurs on a laptop of different branch/mark/vendor ?
 
And so is opening a PR.

I did it once, never again.
At first you get overwhelmed and then you get ignored.

Nothing a new user wants to experience.
This is one of the times where I wish this forum had a "thumbs down" button.

If someone wants FreeBSD to become a better system, then opening a PR is a small amount of effort. If they don't care about others, then don't do it. Will the PR be ignored? No. It will be triaged and looked at. It's possible that after that, if the maintainer of that particular part of the code considers it to not be a high priority, it won't get fixed for a long time, perhaps forever.
 
Nothing a new user wants to experience.
It takes few minutes to go through the rules, few more to actually open a call. So really nothing bad to experience there. And you still have possibility to ask here in forums for guidance.

To your PR -- what are you complaining about? You replied to that PR within 24hrs that it's ok and gave even the solution there. Not to mention it's port related issue, not base.
 
I think i overreacted a bit. I am sorry.

Just felt a little helpless at that time and wished there was any feedback.
Thank you.

Feedback from a PR? You are pointing out a real problem, but that problem exists in most bug tracking mechanisms. The party that submits the bug report often doesn't hear back. In expensive software with big-$$$ service contracts, this is handled by humans interacting: The customer who filed the bug report will send follow-up e-mails or make phone calls, and a good service organization will keep the customer informed of what is happening. In free software, with its very limited budgets for support (meaning: zero budget!), that doesn't work, so it relies on the goodwill of developers.
 
This is one of the times where I wish this forum had a "thumbs down" button.

If someone wants FreeBSD to become a better system, then opening a PR is a small amount of effort. If they don't care about others, then don't do it. Will the PR be ignored? No. It will be triaged and looked at. It's possible that after that, if the maintainer of that particular part of the code considers it to not be a high priority, it won't get fixed for a long time, perhaps forever.
I have in general positive feedback on entering problems.
But it need some work because you must formulate the problem in this way that a developer can do something usefull with it in a reasonable time, so you must remove "noise".
Entering problems allows improvement in software quality.
 

zirias@

Developer
You can't say anything useful about the "service quality" from opening just one single PR.

I totally agree with ralphbsz, you can't operate something like a professional "helpdesk" as a FOSS project, it wouldn't be worth the cost. I wouldn't just name "goodwill" as a factor, but also the time actually available.

In my experience, some PRs are really "ignored", some others are worked on very eagerly. But most are actually handled in some way (with at least some feedback). When I get "assigned" a PR (not technically possible, you need to be committer for that, but "logically" possible through the maintainer-feedback flag), I really try to help people, and many others seem to do the same.
 
RNH : I don't have any notebook with FreeBSD running so I'm guessing here. Can you run the command sysctl hw.acpi.battery to see if it gets through? Does that crash your system? While it may not be ideal (not sure what disabling ACPI does to a notebook in general) you could try to disable ACPI as mentioned here, paragraph 4.2. Try again once rebooted with ACPI disabled if you still see the crash. If not you'd be able to use top at least till it gets resolved.

top command is failing because part of its code is querying battery status using syscall that is unfortunately crashing in kernel (trapping due to div by 0 but essentially crashing).
 
  • Thanks
Reactions: RNH
OP
RNH

RNH

RNH : I don't have any notebook with FreeBSD running so I'm guessing here. Can you run the command sysctl hw.acpi.battery to see if it gets through? Does that crash your system? While it may not be ideal (not sure what disabling ACPI does to a notebook in general) you could try to disable ACPI as mentioned here, paragraph 4.2. Try again once rebooted with ACPI disabled if you still see the crash. If not you'd be able to use top at least till it gets resolved.

top command is failing because part of its code is querying battery status using syscall that is unfortunately crashing in kernel (trapping due to div by 0 but essentially crashing).
Wow you were right I tried sysctl hw.acpi.battery
And the error was produced again
I will try turning off ACPI and will report the result here
 

Attachments

  • CamScanner 07-31-2022 16.29_2.jpg
    CamScanner 07-31-2022 16.29_2.jpg
    360.9 KB · Views: 12
  • CamScanner 07-31-2022 16.29_1.jpg
    CamScanner 07-31-2022 16.29_1.jpg
    289.4 KB · Views: 12
OP
RNH

RNH

Well turned off ACPI in the bootloader and it didn't turn well
Please disregard my info about MC error.
The kernel is crashing in function acpi_battery_sysctl() as indicated in the trap info due to division error. You won't fix this by reading handbook (but you should use handbook to get yourself familiar with the FreeBSD).

You can/should open a problem report (PR) to let the developers know. Please do check the howto on that page to get familiar with the process.
Before that make sure that:
1) you are using GENERIC kernel (which you confirmed you are using default installation)
2) you have up-to-date FreeBSD running (so either 12.3, 13.0, 13.1)
3) you have dump available (vmcore.N in /var/crash, maybe zipped ; N is the number starting from 0)

When you open a PR you can share the information about the system (hw details, FreeBSD details), possibly pictures of the dump you have a the actual dump file.

In the dump pictures you shared I see dump completed so if you have enough free space in /var/crash you should see a proper dump there. You don't need debugging tools for this.
The only other PR opened for this topic was back in 2009 - PR 122056
Sure I will open a PR asap
Thanks for the help!
 

Attachments

  • CamScanner 07-31-2022 16.29_3.jpg
    CamScanner 07-31-2022 16.29_3.jpg
    288.9 KB · Views: 15
You could probably compile custom kernel with atpic but that's not worth a trouble. PR is a way to go.

It's worth mentioning you should check if you have the latest BIOS too, maybe there are some acpi fixes from vendor.
Btw. do you see those core files being created under /var/crash? I had a brief look at the AH530 owner's manual - what do you have under BIOS setup -> Advanced -> Misc configurations -> Hardware Power Management? Maybe worth trying to toggle it to different state (from enabled to disabled and vice versa) and try again.

If you open a PR please share it here too. It's nice to have a link to a PR for other people who may google this thread.
 
  • Thanks
Reactions: RNH
OP
RNH

RNH

You could probably compile custom kernel with atpic but that's not worth a trouble. PR is a way to go.

It's worth mentioning you should check if you have the latest BIOS too, maybe there are some acpi fixes from vendor.
Btw. do you see those core files being created under /var/crash? I had a brief look at the AH530 owner's manual - what do you have under BIOS setup -> Advanced -> Misc configurations -> Hardware Power Management? Maybe worth trying to toggle it to different state (from enabled to disabled and vice versa) and try again.

If you open a PR please share it here too. It's nice to have a link to a PR for other people who may google this thread.
I updated bios and unfortunately it didn't have the misc configuration part.
But I just detached the battery from my laptop and well it worked

Something that I forgot to write here and I don't know if it is related to the problem or not is that my laptops battery is kinda dead and it never gets charged(it always needs to be plugged in power) so actually the problem is pretty much solved for me because with or without the battery my laptop functions the same.

And I will report the PR and I will keep you guys posted here
 
Great you found a workaround. 👍
Code in sys/dev/acpica/acpi_battery.c has handful checks to avoid dividing by 0 but it's really hard to guess without a crash dump what was going on. Your battery may have revealed some issue with the code.
 
  • Thanks
Reactions: RNH
Top