Re: Constant coredumps

[Todd Gruhn <tgruhn2%gmail.com@localhost>]

You wont believe this. I unhooked the USB hub, and the prob went
away -- then it came back. Something else is doing this.

On Wed, Mar 2, 2022 at 12:15 AM Riza Dindir <riza.dindir%gmail.com@localhost> wrote:
>
> Hello all
>
> I wanted to give more detail of the crash dump of my problem.
>
> I remember that i send the stack trace that i have gotton from crash to the list back in august.
>
> The thing is this. I have a mouse that i switch on. This is a wireless mouse connected to the external usb hub. The hub is a cheap one and can be a problem. Anyways. I remember that the stacktrace had the usb HID device when it was connecting.
>
> I first was switching on the mouse. Then running startx. Most of the time, the X server was freezing, and the ayatem was resetting. And after the reset the core dump was being saved. So i thought i should switch the mouse on after the X server and the WM started. Now there are no coredumps, or resetting the syatem related to this.
>
> Also as Ignatios pointed out, maybe the system is not shut down properly. That might be one reason. I am no expert but ispecting the core would give more detail.
>
> To restart or shutdown the system i use the shutdown command with -p to powerdown/shutdown and -r to restart the system.
>
> Best Regards
> Riza
>
> On Tue, Mar 1, 2022, 23:03 Todd Gruhn <tgruhn2%gmail.com@localhost> wrote:
>>
>> Another user pointed out they had problems with
>> core-dumps and USB. The pointed out the problem was
>> the USB hub. I disconnected my USB hub; the problem
>> went away.
>>
>> What does a USB-hub have to do with a core-dump?
>>
>> On Tue, Mar 1, 2022 at 5:59 PM <ignatios%cs.uni-bonn.de@localhost> wrote:
>> >
>> > hello,
>> >
>> > On Mon, Feb 28, 2022 at 10:50:00AM -0500, Todd Gruhn wrote:
>> > > I noticed that every time I   start NetBSD I get a message that says
>> > > it compressing netbsd.core.
>> > >
>> > > Why is this happening? Has anyone noticed this?
>> >
>> > Every time? how many files are in /var/crash? what do
>> >
>> > df -h /var/crash
>> > and
>> > du -h /var/crash
>> > show?
>> >
>> > Normally, this means that every time you're booting, the system finds
>> > the signature of a system core dump in the swap partition.
>> >
>> > In this case, one of the startup files will save the coredump from
>> > the dump partiton - normally the (first) swap partion - to the filesystem,
>> > and save the (compressed) current kernel alongside, so that somebody could
>> > use both to find out what the problem is.
>> >
>> > This either means that you always reboot by crashing the NetBSD
>> > kernel, or that the filesystem /var/crash is on is too small to
>> > add your core dump and your compressed kernel, so this never
>> > finishes.
>> >
>> > By looking at the answer to my above questions, you can distinguish the
>> > cases.
>> >
>> > If you don't intend to debug an old kernel crash, you can get rid of
>> > it by running
>> >
>> > /sbin/savecore -c
>> >
>> > with swap disabled, e.g. in single user mode, or after
>> > swapctl -d /dev/yourdumpdevice
>> >
>> > check for your dump device by
>> >
>> > grep dumps /var/run/dmesg.boot
>> >
>> > It should look similar to this:
>> >
>> > $ grep dump /var/run/dmesg.boot
>> > root on wd0a dumps on wd0b
>> >
>> > so you would
>> >
>> > /sbin/swapctl -d /dev/wd0b
>> > /sbin/savecore  -c
>> > /sbin/swapctl -a /dev/wd0b
>> >
>> > in this case...
>> >
>> > If the message reappears when rebooting after that, your kernel had
>> > crashed again, instead of shutting down cleanly.
>> >
>> > Good luck!
>> >
>> >         -is