Opened 4 years ago

Last modified 3 years ago

#12412 assigned bug

Debugger entered on boot

Reported by: ronald-scheckelhoff-trac Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Servers/input_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #12416, #12713
Has a Patch: no Platform: All

Description

This is related to observations of hrev 49665 and 49666 installations.

The referenced debugger trap occurs only on the first boot attempt. Subseqently, everything is fine.

Attachments (4)

IMG_0883-1.JPG (256.9 KB) - added by ronald-scheckelhoff-trac 4 years ago.
Snapshot of screen
IMG_0127.JPG (1.8 MB) - added by vidrep 3 years ago.
syslog.old (512.1 KB) - added by vidrep 3 years ago.
syslog (372.5 KB) - added by vidrep 3 years ago.

Change History (19)

Changed 4 years ago by ronald-scheckelhoff-trac

Attachment: IMG_0883-1.JPG added

Snapshot of screen

comment:1 Changed 4 years ago by ronald-scheckelhoff-trac

Note: this was a first boot attempt from an ISO created CD (downloaded nightly), for the purpose of installing the OS. A second boot attempt works fine (both hrevs), and installs the system.

Last edited 4 years ago by ronald-scheckelhoff-trac (previous) (diff)

comment:2 Changed 4 years ago by ronald-scheckelhoff-trac

Maybe this was done on purpose to test something?

comment:3 Changed 4 years ago by mmlr

The success message is a part of the debugger startup, not the actual debug call reason. Or why do you think that this was left in place on purpose?

If this is reproducible, please get a stack trace of the thread using the bt or sc command. Unfortunately I don't think there's a way to print the actual debugger call message from the command line version of the debugger yet.

comment:4 Changed 4 years ago by ronald-scheckelhoff-trac

Relative to the bt, I think the debugger was frozen. I seem to be having problems reproducing the issue, but it could be that this happens only if the hard drive has a previous installation (of another OS) with GRUB on it. I'll continue to attempt to reproduce the issue, and try to get a back trace.

comment:5 Changed 4 years ago by pulkomandy

Component: SystemServers/input_server
Owner: changed from nobody to korli

From the debugger command line you can use the save_report command to get a complete report, however if booting from a read-only CD this won't be of much use.

The crash is in input_server, so you may have trouble using the keyboard. This would explain the "freeze".

comment:6 Changed 4 years ago by diver

Blocking: 12416 added

(In #12416) Probably a dupe of #12412

comment:7 Changed 3 years ago by vidrep

Just had it happen when trying to install hrev49736 x86_gcc2 from a CD using the anyboot image.

comment:8 Changed 3 years ago by vidrep

Are there any steps that can be taken at the debugger prompt to extract any useful information?

comment:9 Changed 3 years ago by pulkomandy

You can use save_report to save a report file to the desktop, but unfortunately this won't be very useful when booting from CD. As mmlr mentionned, typing bt or sc to get a backtrace, and taking a picture of that, would provide info as to where in the code the crash is happening.

comment:10 Changed 3 years ago by vidrep

Yesterday, before your reply, I had run a couple of backtraces of some of the threads. I have attached a photo, which may or may not be of use in finding the issue. I tried to trigger the fault again this morning by trying about 25 installation boots, but nothing happened.

Changed 3 years ago by vidrep

Attachment: IMG_0127.JPG added

comment:11 Changed 3 years ago by mmlr

This might be fixed in hrev49756 if the input_server was actually in the process of starting to watch for device entries. If it's still possible to reproduce it would be helpful to get a live serial log that would capture a back trace of the crash.

comment:12 Changed 3 years ago by vidrep

A suggestion to change the title to be more specific: "Debugger entered on first post install boot"

comment:13 Changed 3 years ago by vidrep

Had it happen with hrev49760 x86_gcc2. Unfortunately I was not serial logging at the time. I have attached the syslogs in the event they may be useful.

Changed 3 years ago by vidrep

Attachment: syslog.old added

Changed 3 years ago by vidrep

Attachment: syslog added

comment:14 Changed 3 years ago by diver

Blocking: 12713 added

(In #12713) Probably a dupe of #12412

comment:15 Changed 3 years ago by korli

Owner: changed from korli to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.