View Single Post
  #6   (View Single Post)  
Old 25th October 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,984
Default

Quote:
Originally Posted by sacerdos_daemonis View Post
Everything was working fine before the upgrade to 6.3. It might be possible drivers or configuration changed, but that would be surprising. At least to me.
When you upgraded, did you also upgrade packages with # pkg_add -u? I ask because cdrecord is a component of the cdrtools package, it is not part of the base OS, and while older packages should still work, there can sometimes be problems due to inadvertant calls to libraries with API changes.
Quote:
My knowledge of shells is very limited. I only use the default shell, which I believe is kshell. I have no idea what else the OS might use behind the scenes. I shall check out those files if I can find them.
Let me be clear. Memory and other limits are a function of the user's login class. There are several login classes, defined in /etc/login.conf, and selected when you provision a user. There are three useful classes defined in that file for admins to be aware of: default, staff, and daemon. The default class is for default users, and has minimal resources -- memory, open files, running processes -- available. The daemon class is used by running services such as those started at boot time. The staff class is for human users who expect to use the bulk of the resources on the computer. As an example of this, most browsers will fail if the user is running in the default login class. You can change a user's class from "default" to "staff" with user management tools such as chpass(1).

Limits defined by the user's class are easy to see from the user's shell, using "limit" with Bourne-based shells such as ksh(1), and with "ulimit" from C-based shells such as csh(1).

---

For additional clarity, there is absolutely no connection between your graphics chipset and cdrecord's failure. The firmware message is not related to the problem. But, since you noticed the firmware error message, here is what I can see from your dmesg(8):
Code:
OpenBSD 6.3 (GENERIC.MP) #10: Wed Aug 22 16:42:31 CEST 2018    root@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
That first line tells my you are using 6.3-release with syspatches through August 22, on the amd64 architecture. There are some newer errata patches, but they do not appear to be related in any way to your cdrecord problem or your graphics firmware error message.
Code:
bios0: vendor LENOVO version "D7CN30WW(V3.03)" date 04/18/2016
bios0: LENOVO 80LM
These two lines indicate you have a Lenovo B51-80 laptop. There is a newer BIOS available from Lenovo: V3.08, dated 04/16/2017. I do not know what's in the BIOS update, but my guess is it will include recent Intel processor security mitigations.
Code:
cpu0: Intel(R) Core(TM) i5-6200U
This line indicates you have a Skylake processor. Skylake integrated graphics are a relatively recent support addition to OpenBSD. Support began with release 6.2.
Code:
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 520" rev 0x07
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 (ignored)
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
The location of these messages within the dmesg() show that the firmware error message is produced during boot, before X is started. The message indicates that Intel's GuC -- a parallel workload scheduler -- will not be enabled without Intel's firmware.
Code:
cd0 at scsibus1 targ 1 lun 0: <HL-DT-ST, DVDRAM GUE0N, T.02> ATAPI 5/cdrom removable
The OS discovered your optical drive, a CD/DVD/DVD-RAM device. Are you able to use the drive with tools included with the OS, such as playing or burning CDs with cdio(1)? That would indicate if your cdrecord problem is due to the utility, and not to something else. The Multimedia section of the OpenBSD FAQ should be helpful for CDs and DVDs.
Code:
1:0:0: mem address conflict 0xfffe0000/0x20000
"ATI Radeon HD 8670M" rev 0x83 at pci1 dev 0 function 0 not configured
It appears your laptop has "hybrid" graphics - both Intel and Radeon. The Radeon device is not available due to internal addressing conflicts. Generally, OpenBSD only functions well on systems with "hybrid" graphics when one of the two graphics chipsets are disabled in BIOS.
Code:
error: [drm:pid60259:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
error: [drm:pid60259:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
error: [drm:pid60259:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
These messages also appear during the boot up phase. These error message conditions were added to drm(4) kernel support at 6.2, as part of the support added for Skylake. They are produced when hardware is not behaving as the drm() driver expects. It is unclear to me what the cause might be. Disabling the Radeon hardware in BIOS might eliminate them.

Your Xorg log indicates that X is using the default modesetting(4) driver with drm(4).

Last edited by jggimi; 25th October 2018 at 03:43 PM. Reason: one typo
Reply With Quote