Re: [opensuse-virtual] Best Practices / Details for Serial Console debug-level logging when using Xen + systemd ?

...

...

On 28.06.13 at 22:58, ar16 wrote: As I've been working on figuring out serial console setup for Xen, I now notice an OOPS on boot

[ 34.971630] ------------[ cut here ]------------ [ 34.971639] WARNING: at /home/abuild/rpmbuild/BUILD/kernel-xen-3.7.10/linux-3.7/drivers/tty/tty_io.c:14 30 tty_init_dev+0x19a/0x1d0() [ 34.971640] Hardware name: System Product Name [ 34.971642] tty_init_dev: tty driver does not set tty->port. This will crash the kernel later. Fix the driver! [ 34.971643] Modules linked in: xen_scsibk blkbk domctl blkback_pagemap netbk xenbus_be gntdev evtchn binfmt_misc snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sr_mod radeon ttm drm_kms_helper soundcore drm ppdev ata_generic i2c_algo_bit serio_raw k10temp snd_page_alloc pata_atiixp sp5100_tco i2c_piix4 i2c_core shpchp sg r8169 sky2 pci_hotplug parport_pc parport floppy 8250_core asus_atk0110 button n_hdlc slhc nfsd auth_rpcgss nfs_acl nfs fscache lockd sunrpc autofs4 hid_generic usbhid hid linear ohci_hcd ehci_hcd usbcore usb_common scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh xenblk cdrom xennet sata_sil24 serial_core cpuid edd fan thermal processor thermal_sys hwmon dummy sha512_generic sha256_generic sha1_generic ablk_helper cryptd lrw aes_x86_64 xts gf128mul xfs btrfs zlib_deflate libcrc32c dm_snapshot dm_crypt dm_mod raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid10 raid1 raid0 [ 34.971684] Pid: 1057, comm: rs:main Q:Reg Not tainted 3.7.10-1.16-xen #1 [ 34.971685] Call Trace: [ 34.971697] [<ffffffff80008ae5>] dump_trace+0x85/0x1c0 [ 34.971702] [<ffffffff804f8449>] dump_stack+0x69/0x6f [ 34.971707] [<ffffffff8002edc9>] warn_slowpath_common+0x79/0xc0 [ 34.971711] [<ffffffff8002eec5>] warn_slowpath_fmt+0x45/0x50 [ 34.971714] [<ffffffff8031f38a>] tty_init_dev+0x19a/0x1d0 [ 34.971719] [<ffffffff8031fca8>] tty_open+0x318/0x580 [ 34.971723] [<ffffffff801376df>] chrdev_open+0xbf/0x1e0 [ 34.971727] [<ffffffff80131526>] do_dentry_open+0x206/0x290 [ 34.971731] [<ffffffff80140391>] do_last+0x2e1/0xed0 [ 34.971735] [<ffffffff80141f03>] path_openat+0xc3/0x4f0 [ 34.971738] [<ffffffff80142cf4>] do_filp_open+0x44/0xb0 [ 34.971741] [<ffffffff801326e3>] do_sys_open+0xf3/0x1e0 [ 34.971744] [<ffffffff8050ad0b>] system_call_fastpath+0x1a/0x1f [ 34.971751] [<00007f4d6b6f2b0d>] 0x7f4d6b6f2b0c [ 34.971753] ---[ end trace ca20eeab42859431 ]--- [ 34.971761] Warning: dev (tty10) tty->count(0) != #fd's(1) in tty_open

As the changes to drivers/xen/console/console.c show that patches.xen/xen3-patch-3.7 does, the Xen console driver has been modified to deal with that situation (as obviously I had seen those warnings too earlier on). However, posting just the fragment above makes this all guesswork anyway, as it remains unclear what "console=" and "xencons=" options you may have on your kernel command line.

I'm NOT sure if this is related to some `shutdown` issues I'm having; trying to figure out what's related, and what's not.

Jan, I'm cc'ing you just to 1st ask -- does this ^^^ discussion/oops belong here in -virtual, or over on the -kernel side?

I very much doubt that kernel side console handling issues matter with reboot, which is done entirely in the hypervisor (even more so that you get a message from the hypervisor stating that it at least started the reboot sequence, i.e. control wouldn't return to the Dom0 kernel after that point). Jan -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org